ckyl a écrit 3877 commentaires

  • [^] # Re: Il y aurait juste un probleme

    Posté par  . En réponse à la dépêche Un moteur de recherche de code source OpenSource. Évalué à 4.

    Non il vaut mieux utiliser les fonctions strlcpy et strlcat : http://www.courtesan.com/todd/papers/strlcpy.html(...)

    C'est bizarre la glibc si prompte a ajouter des extensions non standard dans tout les sens d'habite n'a toujours pas pensée à celles ci... Pourtant des fonctions de manipulation de chaîne de caractère non trompeuses et faciles a utiliser ca changerait dans la libc !
  • [^] # Re: Autoroutes

    Posté par  . En réponse au journal Pour ceux qui vivent en couple : comment vous faites pour la supporter ?. Évalué à 2.

    > Je préfère finir ma course dans un champ plutot que dans un camion sur la file de
    gauche.

    Je n'ai pas parler d'accidents mais d'accidents graves c'est a dire d'accidents qui ont entrainé l'hospitalisation d'au moins une personne pendant au minimum 6 jours.

    http://www.route.equipement.gouv.fr/RoutesEnFrance/savoirplus.htm(...)

    Pour ce qui est des tués les autoroutes representent 7,2% des tues alors que les nationales et departementale 75%. Il faut bien sur ajuster ces chiffres au kilometrage total et au kilometrage parcouru sur ces routes. Et la seconde partie n'est pas triviale a faire. Enfin moi pour faire 900 bornes dans la journée je sais ou j'ai le plus de risque de me planter sans hésitation....

    http://www.securite-routiere.gouv.fr/IMG/Synthese/dep_accidentologi(...)
  • [^] # Re: Hmfff

    Posté par  . En réponse au journal La valse des Live CD .... Évalué à 2.

    > Bon, déjà,il y a trop de paranthèses dans ton texte. C'est choquant.

    Bouarf je code en scheme ca me choque pas perso.
  • [^] # Re: toto

    Posté par  . En réponse à la dépêche Un moteur de recherche de code source OpenSource. Évalué à 2.

    Tu sais même les gens bien disent des conneries. D'ailleur statistiquement même eux doivent en dire plus que de choses inteligentes.

    Pour être un peu serieux replace toi dans le contexte de l'époque... "Le goto c'est le mal" est une approche aussi stupide que d'en foutre partout et de produire du code incomprehensible. C'est un outil pratique qu'il faut utiliser avec justesse.
  • [^] # Re: Petite mise au point

    Posté par  . En réponse à la dépêche Sortie de FreeBSD 5.3. Évalué à 3.

    Ca ne me semble pas la vonloté qui manque c'est simplement le nombre de devels, comme pour presque tout les defauts actuels de sourcemage. C'est une distrib qui part sur un super principe, il est très simple de s'impliquer dans le projet, comprendre comment marche le système de packaging et faire ton premier spell ne doit pas te prendre plus de 2h.

    Bref quand un devel ne sera plus obligé de maintenir 250 softs, quand il y aura plus de 3 personnes pour faire remonter les bugs sur les applis autres que KDE/Gnome/Xchat/bash & co le problème sera résolu.

    En effet la 1.0 peut être un tournant si l'annonce de la sortie arrive a injecter assez d'utilisateurs pour repartir sur un "cycle vertueux" plus d'utilisateurs => plus de qualité => plus d'utilisateurs. Pour le moment, quoi qu'on a vu quelques nouvelles têtes sur #sourcemagefr depuis la sortie de la nouvelle ISO, on reste à un nombre de personne gravitant autour du projet trop faible pour passer a l'étape suivante... avis aux amateurs !

    Il me semble que plus ca va plus les petites distros s'ecroulent sous la complexité de ce qu'est devenu linux. Quand on voit que maintenant même la stabilisation du noyau est laissée en charge aux distribs j'ai un peu peur pour l'avenir.
  • [^] # Re: Petite mise au point

    Posté par  . En réponse à la dépêche Sortie de FreeBSD 5.3. Évalué à 3.

    > J'adore les gens qui se permettent de parler sans savoir ;)

    Regarde le nombre de bug/patch que j'ai soumis. Tu peux aussi grepper ton /var/lib/sorcery je suis sur que tu me trouveras dedans... Donc le sans savoir tu peux repasser.

    > disons que c'est une distribution source, qui part donc de sources fournies

    Zut on se demande pourquoi on applique des patchs pour ameillorer les choses. Je me demande aussi pourquoi je me fais chier a faire des configurations par defaut qui juste marchent. Pourquoi il me faut souvent 3 jours pour tester toutes les dependences d'un spell (non trivial) pour être sur de ne pas foutre la merde.

    Être une distrib source n'est pas une excuse pour ne rien foutre au niveau du packaging. Tu es au courant que sourcemage ne gere meme pas les ACLs ? On parle de SELinux alors que j'ai pas vu le debut de polices coherentes. Tout ca ca se nomme l'integration et c'est justement le boulot des distros. Quand je vois que les spells gnome ne gerent meme pas les types mimes alors que 2.8 est tombé dans stable je suis vraiment mort de rire quand a ta vision de ce que doit faire une distro source....

    Je ne parle meme pas de la branche stable d'smgl qui est plutot une farce vu qu'il n'y a aucune QA derriere.

    Note : nmap 3.76 iz out depuis 3 jours et se baser sur les 10 applis le plus utilisée c'est un peu facile :-)

    > M'enfin, ça n'est peut-être qu'une impression...

    Exemple débile, je fais 5 a 10 FPS de plus a ET sous FreeBSD alors que ca tourne en emulation binaire linux...
  • [^] # Re: Petite mise au point

    Posté par  . En réponse à la dépêche Sortie de FreeBSD 5.3. Évalué à 1.

    > Tu pourrais avoir ne serait-ce qu'un léger sens de l'humour ? (:

    Les affirmations a deux balles qui transforment linuxfr en poubelle c'est un tantinet lourd

    > J'utilise couramment sont à jour dans les paquets dès le lendemain au plus tard.

    C'est bizare slune qui a fait du bruit ici même est resté 30 jours dans le bugzilla avant d'être ajouté a games et est toujours en version 0.7 depuis. Si tu veux j'ai des tonnes d'exemples comme ca. Alors tu dois pas utiliser grand chose :-)

    De plus un jour pour "tester" tu crois pas que c'est peu ?

    > Autre chose : tu continues à utiliser gentoo sur PPC alors que ce n'est pas très facilement utilisable apparemment. Pourquoi ? et quelle autre distrib' PPC as-tu déjà utilisées ?

    C'est la plus utilisable des distribs que j'ai essaye sur ppc. fedora rawhide est prometeuse mais si ppc n'est pas encore supportée officiellement ce n'est pas pour rien, sourcemage c'est rigolo mais j'en ai un peu ma claque d'ouvrir 3 bugs par jour avec les patchs associes pour que je puisse utiliser ce que je veux et gentoo qui malgré tout offre a peu pres tout les logiciels dont j'ai besoin au prix de quelques efforts mais bien moindres que de devoir packager 3 softs par semaine.

    L'iso de de_moya/benoit fonctionne tres bien sur ppc, seulement l'approche multi archi de sourcemage c'est... inexistant. Si ca passe t'as de la chance autrement tant pis. De plus je l'ai virée pour d'autres raisons.

    Autrement tu peux participer au port de FreeBSD sur ppc pour revenir dans le sujet, ca boot deja, toujours, en single user ! Et tu peux aussi contribuer au support de la gestion d'energie a NetBSD...
  • [^] # Re: Petite mise au point

    Posté par  . En réponse à la dépêche Sortie de FreeBSD 5.3. Évalué à 3.

    Tu pourrais ne pas dire n'importe quoi ?

    Une partie des spells sourcemage sont a jour (voir trop a jour pour certains), l'autre est completement a la ramasse voir abandonnée. Rapellons aussi qu'il est facile d'affirmer avoir "XXXX en derniere version" si on se contente de "Ca compile donc ca marche" mais d'un point de vue utilisateur ca n'a aucun interet. D'ailleur lorsque les mêmes gens avancent "C'est deja dans gentoo"... oui en experimental ! Mais ca n'importe qui est capable de le faire, ./configure && make && make install.

    Pourquoi vous vous sentez obligé de jouer aux marchands de tapis ?

    Note: gentoo x86 est pas mal a jour, les autres archis sont pas mal a la bourre... sur mon ppc j'ai juste du rajouter dans les 100 ~ppc pour simplement avoir un système utilisable. Limite lourdingue
  • # Autoroutes

    Posté par  . En réponse au journal Pour ceux qui vivent en couple : comment vous faites pour la supporter ?. Évalué à 10.

    > je prefere les Nationales gratuites et sures qu'aux autoroutes payantes et dangereuses (pas d'eclairage, trop de camions).

    C'est bien connu que les nationales sont eclairees !

    Ha oui au fait, si on fait un bete calcul nb accidents graves/km, les nationales ont plus de deux fois plus d'accidents...
  • [^] # Re: Une remarque à ce sujet...

    Posté par  . En réponse au journal Copie pirate légalisé. Évalué à 2.

    Et il est ou le manque a gagner de la copie privée ?
  • [^] # Re: Ça ressemble à quoi Open BSD ?

    Posté par  . En réponse à la dépêche OpenBSD 3.6 est sorti !. Évalué à 2.

    Peut-etre que s'il avait demandé a quoi ca ressemblait au lieu dire que c'etait de la merde ca serait mieux passé ?

    Note : je me fous particulierement de Microsoft
  • [^] # Re: Et linux PPC?

    Posté par  . En réponse à la dépêche Firefox 1.0 RC1 et autres nouvelles de Mozilla. Évalué à 1.

    Il fut un temps pour Linux offrait une compatibilite binaire avec Windows via Wine. Peut etre alors que la versions Windows est-elle suffisante.
  • # Contest

    Posté par  . En réponse au journal Nouveau logo NetBSD. Évalué à 4.

    http://netbsd.org/Changes/#newlogo(...)

    Over 400 logos were submitted by 238 artists for a NetBSD logo contest

    les autres devaient etre TRES moches :-)
  • [^] # Re: Ça ressemble à quoi Open BSD ?

    Posté par  . En réponse à la dépêche OpenBSD 3.6 est sorti !. Évalué à 1.

    Il y a trois ans les devels de FreeBSD n'insultaient pas leurs utilisateurs...

    Tiens un autre troll !
  • [^] # Re: C'est plus possible

    Posté par  . En réponse au journal Script inintéressant. Évalué à 4.

    Non pour moi un fichier texte c'est un fichier qui contient de l'ASCII ou l'encoding que tu veux qui peut s'ouvrir avec n'importe quel editeur de texte. Mais certainement pas un tas de données binaires necessitant l'application adequat pour etre ouverte.

    Un fichier texte ca se manipule avec cat, grep, awk, sed, perl, des pipes, des redirections de flux etc.

    Ta solution est pire que le mal !
  • [^] # Re: Ça ressemble à quoi Open BSD ?

    Posté par  . En réponse à la dépêche OpenBSD 3.6 est sorti !. Évalué à 1.

    C'est sur que c'est tres utile les copies d'ecrans quand l'userland est le même. C'est une demande toujours aussi ridicule des utilisateurs :-)
  • [^] # Re: concrètement ?

    Posté par  . En réponse au journal La mémoire ? On s'en fout !. Évalué à 3.

    > relire la référence ( http://ccs.ucsd.edu/c/lib_over.html#program%20termination(...(...))

    Ca n'a rien a voir. La recuperation de la mémoire ne depend pas du runtime du C mais du noyau. Quand un processus est créé par le noyau il créer un nouvel espace d'adressage pour le processus, appel le point d'entrer du programme via le loader (le point d'entré n'est pas le main en réalité y'a du code avant) qui lui même appelera main() si tu as un programme en C.

    De même quand ton processus est detruit le tu sors du main(), il y a encore du code qui s'execute dont tu n'as pas connaissance et enfin l'ordre est donné au noyau de détruire le processus et au passage son espace d'adressage.

    Tout les OS "modernes" courant reposent plus ou moins sur ce principe. Et tout le support est fournit pas le processeur pour y arriver facilement. Le fait que ton programme ou ton runtime C libere la mémoire que lui a attribue le noyau n'a rien a voir, ce sont deux concepts différents (cf dans beaucoup d'OS le tas ne peut que grossir même si tu free() toute ta mémoire...)

    Donc pour trouver un système qui ne libère pas la mémoire il faut au choix
    - trouver un noyau avec un VM completement buggé (mais ca devient grave !)
    - peut etre chercher du cote des systemes pour les processeurs sans MMU
    - avec MMU dans l'embarqué mais meme la ca m'étonnerait
    - En regardant du cote de windows 9x et OS 7..8..9 on doit pouvoir trouver des conditions dans lesquels la mémoire n'est pas libérée mais de toute facon on peut faire a peu pres n'importe quoi :-)
    http://developer.apple.com/documentation/mac/Memory/Memory-2.html(...) C'est rigolo de voir l'état de la gestion mémoire d'OS 7
  • [^] # Re: OS

    Posté par  . En réponse au journal La mémoire ? On s'en fout !. Évalué à 2.

    > je me sens vraiment comme un vieux con

    Si tu codes en objet c'est normal, effectivement la construction des objets et l'archi globale des applications fait que tu es beaucoup plus carré de ce coté la.

    Si tu regardes du cote du C (puisque c'est principalement lui qui pose problème) j'ai jamais vu un devel ecrire "propre". Si tu fais un valgrind sur les applis tu verras qu'il n'y a pas de leaks simplement des warnings "Memoire encore referencee mais non liberee" par ce que ca valait pas le coup de saloper le soft de code inutile. La ou c'est propre dans des destructeurs et se fait en 80 caracteres en P0O; en C tu auras souvent un pavé de 50 lignes pour reussir a terminer proprement, donc on ne fait que ce qui est necessaire et en utilisant atexit() par exemple.

    Genre tu ecris un filtre qui construit un arbre a partir de stdin et qui en fait XXX sur stdout. 99% des devels ne vont pas libérer la mémoire, il leur suffirait de faire un parcours recursif s'il y avait besoin mais tant que le cas special ne se presente pas.... Si le même devel est en train d'écrire une lib qui s'interface sur graphviz il fera une fonction pour libérer sa structure.
  • # compilation

    Posté par  . En réponse à la dépêche Patch pour le support du C++ dans le noyau. Évalué à 8.

    Ca tombe bien ! Deux news plus bas on apprennait qu'on pouvait compiler son noyau en 15 secondes maintenant qu'il y a du C++ on va pouvoir le compiler en 15 heures !

    Aïe patapai !
  • [^] # Re: OS

    Posté par  . En réponse au journal La mémoire ? On s'en fout !. Évalué à 3.

    T'arrives pas a comprendre la différence entre maitriser a tout instant ce qui est alloué mais volontairement ne pas s'emmerder a faire des liberations que l'on sait ne servir a rien (typiquement si ton cgi construit une liste chainee qui te sers durant une grande majoritée du temps d'execution) et coder comme un con et ne pas savoir gérer sa mémoire ?

    Le "il faut pas le faire *jamais" est aussi stupide que le mec qui ne comprend pas qu'il fait mal pour moi. C'est a toi de savoir ou c'est important et ou ca l'est pas. Tu _maitrises_ ton code, son environement et les parametres que tu souhaites optimiser et tu codes en fonction de ca. Evidement tu codes pas de la même manière si tu bosses sur de l'embarqué sur un proc sans MMU, que lorsque tu ecris un filtre UNIX, ou une usine a gaz de 10 000 000 de lignes de code !

    Note: personne n'a contesté jusque la que perdre les references sur de la mémoire allouée était une erreur monstrueuse !
  • [^] # Re: C++

    Posté par  . En réponse à la dépêche Patch pour le support du C++ dans le noyau. Évalué à 5.

    Tu peux bien ecrire des drivers I/O en (un sous ensemble du) C++ via l'I/O kit.
    XNU pour lui est du C pur et dur.

    http://developer.apple.com/documentation/DeviceDrivers/Conceptual/I(...)
    http://developer.apple.com/documentation/Darwin/Conceptual/KernelPr(...)

    Pour ce qui est du C++ dans le noyau je crois que linus a deja dit ce qu'il en pensait dans le passe :

    http://kerneltrap.org/node/view/2067(...)

    Je lis plus lkml mais je pense pas que son avis soit beaucoup différent maintenant...
  • [^] # Re: esd suxor des ours népalais...

    Posté par  . En réponse au journal Compte rendu d'installation Ubuntu. Évalué à 3.

    > Tant qu'on jette ESD on aura déjà fait un grand pas. :-)

    Hum et si on met arstd a la place tu dis quoi ? :-p
  • [^] # Re: esd suxor des ours népalais...

    Posté par  . En réponse au journal Compte rendu d'installation Ubuntu. Évalué à 4.

    Et quand tu as retiré ce qui sert pas dans tout les cas d'utilisation différents de linux il te reste les repertoires kernel/ fs/procfs/ et mm/ (quoi que on doit pouvoir trouver un patch pour systeme sans MMU)... Avec ce raisonement on va avancer vite ou alors a tout passer en userland linux va devenir un micronoyau avant que Hurd soit sorti !

    Dis moi tu connais les modules noyaux et la recompilation pour adapter l'outil a ses besoins ?

    Autrement FreeBSD (au hasard) qui est bien connu pour être un OS uniquement destiné au desktop ne pose aucun probleme de ce cote la depuis.... oula je sais meme plus
  • [^] # Re: Mauvais débat.

    Posté par  . En réponse au journal La mémoire ? On s'en fout !. Évalué à 1.

    s/tas/pile/

    Je parlais dans le cas ou tu termines l'execution... C'est sur que c'est tres grave le delete manquant dans un espace d'adressage qui va etre detruit dans la seconde :-)

    Si ton appli a fait son job apres tu t'en fou le système est la pour ca d'ailleur dans tout les softs que j'ai lu (ok je code en C) j'ai pas croisé souvent de gens qui avaient de bonnes habitudes...

    Apres j'ai pas lu le thread de fclc++ et je m'en fou donc je n'ai pas repondu la premiere fois en connaissant le contexte (relire mon post).
  • [^] # Re: Mauvais débat.

    Posté par  . En réponse au journal La mémoire ? On s'en fout !. Évalué à 0.

    > Là, je n'ai pas de réponse mais je pense que oui de plus en plus.

    Heu comment dire tu sais comment fonctionne les VMs ? :-)

    > J'aimerai urler : NON, PAS DE FUITE DE MEMOIRE, c'est crade au possible et ca montre qu'on ne maitrise pas ce que l'on fait.

    Ce n'est pas une fuite mémoire. Une fuite c'est que tu perds toutes les references sur la memoire que tu as alloué. La effectivement c'est une erreur de conception et c'est a corriger.

    Ne pas liberer la mémoire avant la terminaison de l'execution c'est eclaircir le code et une "optimisation"

    if (xxxx)
    exit(1);

    C'est un tantinet plus propre qu'un
    if (xxxx) {
    /* 45 lignes pour desallouer toute la memoire allouee */
    exit(1);
    }

    C'est exactement la meme chose et c'est meme plus rapide ! (liberer toutes les vmas d'un processus est un tantinet plus rapide que 47 540 free())