lorinc

D'autre part, c'est la faute à ATI si les dernières version de leur drivers ne sont plus compatible avec la solution XGL et cie. les distros ne font que prendre les versions à jours des softs. Ils ne vont pas s'amuser à avoir 5 ans de retard, sous prétexte qu'un setup particulier usant d'un blob immonde ne marche plus... Sinon, rien à voir, mais cool quand même : Vous savez quels chipsetr wifi acheter, maintenant

En fait c'est setvbuf() (ANSI, les termios() sont des fcontions POSIX). Il y a trois mode : Visiblement, les fichiers sont ouverts avec _IOFBF. Je voulais savoir si c'est spécifié dans la norme. Ça m'étonerait très fort que la norme ANSI définisse le comportement par défaut de la libc. quand on regarde dans le man, on trouve Je pense (mais je n'ai pas le texte de norme sous les yeux) que ce n'est pas défini par la norme, mais que c'est le comportement par défaut de la libc GNU.

JE ne pense pas que ça ait à voir avec la norme ansi, mais plutôt avec le type de descripteur auquel tu accèdes. stdout est quand même un descripteur hyper particulier. essaye dans un premier temps en faisant un stty -icanon (qui enlève le mode canonique). Si ça marche, tu peux modifier le comportement d'un terminal directement en C avec les termios

normal, par défaut c'est toujours le 3.5.* qui est proposé. le 4.0.* doit pouvoir s'installer en faisant un tour dans le gestionnaire de paquet uniquement.

attends, le foie, ça me connait, hein, c'est pas comme si chaque année j'allais déposer une gerbe de fleurs sur sa tombe...

Je signale quand même que mon "foie" au lieu de "foi" était volontaire pour faire un jeu de mot

il suffirait d'éclaircir très légèrement la couleur des infos complémentaires (en espérant que ce soit pas une couleur partagée avec le skin clair)

et moi, j'ai plus trop de foie en sid...

Oui, effectivement, il y a des distro ou quand kde4 passera d'expérimental à stable, ça risque d'être sportif pour arriver à selectionner les bons paquets (et je ne donnerais pas de noms... )

bah, c'est comme gnome, fraudra sélectionner les 348 paquets de kde à mettre à jour dans le gestionnaire et être patient. C'est la grande force des gestionnaire de package : la difficulté de mise-à-jour est la même pour tous les softs et proche du néant.

bon annif Sentinel :tchintchin:

c'est une contrepètrie... Un peu comme les programmeuses qui compilent le C.

Si même toi, tu confirmes... Oui oui, il boude quand on touche à son petit banc...

| sed 's/....//' EDIT : ach! theo est plus rapide et plus complet que moi

Je suis partagé entre le "youyou" du mec que ça gave de devoir attendre les trois secondes réglementaires à chaque changement de VT, et l'intuition que ça n'a rien à foutre en mode noyau... Enfin bon, tant que ça marche et qu'en plus c'est plus agréable à utiliser...

je pense surtout que les nouvelles fonctionnalités sont développées par l'équipe windows et puis mettent un temps de chien à être portée par l'équipe unix...

les produits de la mofo ont pris la mauvaise habitude d'être mieux foutu et plus à jour sur les plateformes proprio que sur les plateformes libres...

Oui, ben il était très tôt du matin et j'avais pas encore les yeux en face des trous. M'en suis rendu compte après... Les points les plus cracra sont quand même : * les majuscules, surtout que ça coûtait rien de tout mettre en minuscule * l'indentation dégueulasse. Ok, c'est pas dans la norme. En C aussi, c'est pas dans la norme, et pourtant... * les attributs de forme partout. Ça c'est bien gruik. Je croyais que le but des trucs over verbeux à base de langages structurés comme le XML étaient là justement pour arriver à dissocier le fond de la forme...

ben du programme...

Allez, balance le nom qu'on conspue les auteurs un coup...

Ah effectivement, c'est bon à savoir. Apparemment, \address spécifie un nouveau formattage du champs d'adresse, alors que s'il n'y est pas, le formattage par défaut est utilisé. Les commandes \location et \telephone permettent de modifier certaines parties des champs du formattage par défaut.

et puis le jour où tu te retrouve sur une machine avec uniquement vi, tu l'as dans le *** si tu ne sais pas un minimum t'en servir...

patcher le noyal pour qu'il créé l'entrée au bon endroit...

bon, je suis quand même allé fouiller dans le svn de KDE4, donc s'il y avait un bout de projet là dessus, ça se serait vu... Dans le code, je me rappelle avoir croisé un bout de commentaire disant grosso merdo que pour la prochaine release ce serait bien d'utiliser sha256. Cela dit, c'est vrai qu'un vrai framework qui servirait de glue pour les applis KDE à un backend éprouvé (un peu comme phonon en quelque sorte), ce serait vraiment un plus.