Par contre c'est pas fini fini et le code est malheureusement sale, pas documenté, en franglais... Je voulais essayer de contribuer un peu mais j'ai rennoncé.
> Les benchmarks veulent toujours dire quelque chose, au moins dans les cas testés.
Les benchs veulent toujours dire quelques choses mais veulent t'ils dire quelque chose dans la vie réelle ? La principale question est la.
On a vu des tas de micro benchmark présentant des trucs pourri. Mais voila apres analyse il se trouve que le code n'était "jamais" exécuté ou que l'auteur du benchmark s'était complétement vautré.
D'après ce que disent les deux benchs ils mesurents la même chose. Pourtant sur l'un FreeBSD est en 0(1) et l'autre en 0(n). Donc soit ils ne mesurent pas la meme chose soit pas de la même manière. D'un coté NetBSD se fait later et pas de l'autre.
En regardant de plus près "The scalability benchmarks were supplied by F. von Leitner[2]." Mince c'est le même programme qui à fait les deux benchmarks ! Comme cela est-il possible ? Tu aurais une explication a me fournir ?
Il y a des tonnes d'exemples comme cela. Des dizaines de posts sur lkml qui présentait l'overhead de leur patch mais mésurait au mieux le meilleur cas au pire quelque chose qui n'avait rien a voir.
Et pour finir comme d'habitude le bench fourni des phrases vident de sens du point de vue technique pour présenter 4 graphes et l'analyse se limite a XXX roxor. Il n'y a aucun travail pour présenter ce que cela implique réellement ou expliquer le pourquoi le resultat du graphe.
Le meilleur test c'est la vie reelle et non les benchmarks ! Ca ne te fourni pas pourquoi ni où; mais de toute facon la seule chose qui t'interesse c'est qui roxor non ? Tu mets les deux dans ton environement de prod et tu vois lequel s'en sort. Le reste n'est que foutaises ou outil d'aide au developpement (seul endroit ou les micro benchmark sont utiles)
>Donc chacun retiendra ce qu'il voudra de ce journal, moi je me simplifie la vie en n'en retenant que la dernière phrase ! ;-)
Tu devrais regarder le JT de TF1 et n'en retenir que la derniere phrase sans analyse :-)
> = tout utilisateur qui a acces a un prog en setuid root, comme /usr/bin/passwd ?
Tu sors un peu la phrase de son contexte mais l'idée est :
Si tu as le compte d'un utilisateur qui peut elever ses privilege alors tu peux acceder aux mêmes privilèges.
C'est plus ou moins compliqué. Ca va du sudo sans mot de passe, au su via empreinte digitial + mot de passe a usage unique en passant par le traditionel su + mot de passe. Mais au final on doit presque toujours pouvoir y arriver. Pour le setuid tu pourras faire ce que t'autorise le programme ou plus si faille.
> Ton "sudo" fait la résolution des alias toi ?
Non mais alias su="mysu", ou utilisation des variables environement, ou keylogger ou faille local ou.... Bref des attaques veilles comme le monde qui fonctionneront sur 99.9% des machines, le reste étant sécurisé c'est une autre histoire :-)
> Ça me semble plutôt nécessaire pour aller vers une adoption plus massive de la signature numérique à valeur légale
Dans ce cas on ne parle de la même chose et le web of trust doit etre remplacé par une architecture plus officielle type PKI avec autorite de certification et d'enregistrement. La confiance n'a rien a faire la dedans et le certificat doit etre fournis par l'état.
Que 46 personnes indiquent tu es bien colin leroy on s'en fou. Par contre que l'état te délivre le certificat est suffisant. Tu ES ou tu n'ES PAS. En aucun cas tu ES PEUT ETRE (à divers niveaux).
> mais c'est toujours mieux qu'une clé signée sauvagement parce que "je parle avec z0rro sur IRC depuis un an" donc je lui fais confiance.
Non ce n'est pas mieux.
Ce que tu as fait c'est signer la cle de z0rro (tu peux verifier que c'est bien avec lui que tu parlais). C'est le principe même. Voir la personne physique n'apporte rien surtout si tu ne l'as jamais vu. Tu ne fais pas confiance à quelqu'un en signant ca cle tu dis "Cette cle correspond au mec que je connais". A toi de ne pas signer une fausse association cle/personne mais ca, ca depasse largement le cadre de la recontre physique.
A partir du moment ou tu possedes le compte d'un utilisateur qui augmente ses privileges c'est fini, ce n'est plus qu'une question de temps.
Simplement un alias sur su et voila (mais il y a plus subtile).
Ne pas se loger en root n'apporte aucune securite supplémentaire c'est un mythe. Ce que ca apporte c'est que l'on sait quel compte fait quoi rien de plus rien de moins. Je dors beaucoup mieux avec un ssh root et un root qui ne se log que depuis la console qu'avec une machine ou l'utilisateur peut se suer/sudoer... Il ne reste que deux risques, un mot de passe trop faible (c'est bien la le probleme et il est tres facile a resoudre) et une faille ssh. Pour la deuxieme y'a pas grand chose a faire de toute facon.
Passons sur le fait que semantiquement ce n'est pas la meme chose. Tu peux tres bien avoir 2 variables de type different et 2 verrous a prendre. Tiens c'est pas une pile du coup !
Allez on passe sur un vrai exemple pratique qui ferait vomir n'importe quel prof de programmation du cote bien de la force.
Tu me le recodes copy_process sans goto avec des fonctions qui font pas plus d'un ecran toussa ? Je suis sur que tout le monde sera tres content de ta contribution a rendre le noyau moins degeulasse puisqu'il y a toujours moyen de faire autrement
Conditions :
- le code doit marcher
- le code ne doit pas etre plus compliqué a comprendre
- le code ne doit pas etre plus de 10% plus lent
Dans le sens que le système est moins reactif et qu'il bloque plus souvent les mauvais process. Ce n'est pas rare de voir que ton terminal patine pendant quelques dixièmes de seconde, C'etait excusable y'a quelques années maintenant ca fait plus tache :-)
De même la technique de swapping de FreeBSD pour les WS je la trouve bof, pour les serveurs ca se discute plus.
> C'est quoi un problème de locking?
FreeBSD a pris la direction de faire du verouillage fin. C'est utile pour le multi-processeur. Deux CPUs ne doivent pas toucher à la même structure de donnée en même temps, autrement tes informations vont etre dans etat inchorent.
FreeBSD 4 appliquait un "Giant locking" c'est a dire qu'il n'y a qu'une condition de verouillage, tu prends ton verrou en rentrant dans la routine et tu le relaches à la fin. C'est simple mais peu performant si tu fais monter le nombre de processeur.
FreeBSD a choisi de multiplier les conditions de locking, tu peux ne verouiller que ce que tu as besoin. C'est mieux en perf mais c'est plus casse geule. Et FreeBSD essuis encore un peu les platres de ce choix.
D'un point de vu technique j'ai vu qu'ils avaient fait de jolies choses après je n'ai pas testé.
Il faut aussi garder à l'esprit que Dragonfly a pour le moment l'avantage d'avoir une base d'utilisateurs très réduite ce qui permet de developper plus de fonctionalités en passant moins de temps sur le QA. Si tu regardes linux semble aussi vouloir résoudre le problème en laissant la stabilisation aux distribs puis remonté des patchs en upstream.
Mais chez FreeBSD on gère la stabilisation en interne et c'est clairement ce qui a tué la 5.3. Annoncée comme prometeuse il y a longtemps, elle devient decevante, sortie trop tardive ou pas assez parfaite. 8 mois entre 5.2.1 et 5.3 pour quel résultat du point de vu utilisateur ?
Attendons de voir si le changement de release engineering pourra faire sortir FreeBSD d'une trajectoire qui semble allez droit dans le mur tellement linux place la barre haut pour s'assurer une survie. Après c'est utilisable ce message est écrit depuis FreeBSD mais sans cette impression de peut mieux faire ca sera formidable :-)
J'ai du abandonner FreeBSD entre 5.1 (-CURRENT cependant) et j'y suis revennu a 5.3 et pour moi le système a clairement regressé (au revoir ULE...).
La reactivité est à des années lumière de linux, toujours des problèmes de locking qui trainent un peu partout, son qui saccade en monté en charge etc. C'est domage 5- était prometeuse... Il y a 18 mois. Maintenant ca semble être un branche morte qui a trop attendu apres les testeurs, elle n'a plus grand chose d'inovante par rapport à ses concurents.
Reste beaucoup de fonctionalités interessantes, entachees par un amère gout de "pas fini".
De même pour gérer les erreurs un goto permet d'ameillorer la lisibilité en déplacant le code de gestion d'erreur en dehors du code lui même et allege la maintenance car il evite de dupliquer les actions effectuées lors de la gestion d'erreur.
Ce qui me fait marrer c'est qu'on sort toujours l'exemple du goto degeulasse qui saute dans une autre fonction pour expliquer que le goto est mauvais. Mais il me semble que personne de nos jours n'a l'intention de l'utiliser ainsi. Donc plutôt que de parler sur des cas qui n'existe pas, prouve moi qu'il y a plus elegant que le goto pour l'usage qu'on en fait dans la vie reelle.
Tu trouveras dans l'archive google du thread resumé par kerneltrap plusieurs exemples de code. Tu verras aussi que le mec qui a proposé de virer les goto a mis *UN* exemple et qu'il s'est completement vautré et que son code ne marche pas... Plus simple et plus propre on avait dit....
> Je commence a me demander vraiment pkoi des gens aussi bon en info peuvent se permettre de coder comme des porc en ne respectant meme pas les regles de base que on apprend lors des premiers cours de programmation
Par ce que tu as appris a coder des applis userland ce qui n'a a peu pres rien a voir avec un noyau ?
Aller juste un exemple avec un verou, prennons Giant par hasard. Toutes les parties de ton noyau doivent pouvoir faire un lock sur Giant. Tu as la technique où il c'est une variable globale tu fais une jolie macro GIANT_REQUIRED et basta. Ou tu fais une fonction qui va à son tour faire ce que ta macro fait.
Le gain de la deuxième solution est nul et au mieux ca sera pas plus lent si la fonction est inlinée...
Je vois pas pourquoi on la virerait ! Enfin y'en a une tripotée comme ca. De même pour savoir si les peripherique doivent etre en mode verbeux ou non lors de l'initialisation. Quel avantage a une fonction "isVerbose" plutot que de tapper directement dans la variable ? Alors peut etre que tes profs t'auraient tappé dessus mais faut aussi reflechir a ce que tu gagnes reellement et ce que tu risques. Et non pas appliquer betement des principes du type "les goto c'est interdit", les variables globale c'est nul etc.
J'ai pas encore lu le papier pour pouvoir juger du chiffre annoncé dans le journal mais selon ce qui est pris en compte ca pourrait ne pas me choquer plus que ca. Aller chez FreeBSD rien que dans /kern je peux te dire qu'il y a au moins 255 variables globales.
> Le site de SCO je comprends mais linuxgraphic ????
Faudrait arreter de voir les gentils et les mechants.
L'Hacktivsme & co c'est generalement bon pour enc*ler les mouches et passer du status de cyber cretin au cyber hero. Quelle est la difference entre rooter SCO ou linuxgraphics ? tu peux me dire ?
D'un coté ca t'arrange et pas l'autre ? Mais tu sais il existe aussi des gens de l'autre coté. Forcement ca nous, te, fait moins rire. Le gentil pirate d'SCO se transforme en gamin prepubere qui ne sait pas se servir de linux et telecharge des outils tout fait.
Faudrait arreter un peu la. Les deux peuvent être des débiles mentaux, tout comme les deux peuvent avoir fait de jolies choses du point de vu technique.
> J'veux pas dire, mais les débits de Renater sont "énormes" pour ce que l'on en fait
Donc ca justifie que les salles machines des DEUGs (sans compte donc anonyme) servent de base de telechargement ou de lancement de DoS ? Faut bien faire quelque chose de la BP libre non ?
> Je ne suis pas certains que les étudiants utilisent des protocoles lourds autres que le P2P.
Tu oublies les scripts de reinstallation de logiciels tel eclipse & co dans les /tmp :-)
> les autres universités ne me pourrissant pas mon débit.
Non tu pourris le debit de ton "antenne". Sur les campus repartis chaque zone n'a pas accès à 2.5Gb/s. De même les reseaux locaux sont rarement gigabit.
>Deuxièmement, bloquer un traffic car il prend trop de ressources, ce n'est pas de l'incompétence, mais ça s'en rapproche
Si encore il n'y avait que du P2P légal ca serait applicable. Le fait est que 99.99% de la BP utilisé pour le P2P est illégal et viole clairement la jolie charte que tu signes en début d'année. Si tu sais comment filtrer sur le contenu écrit vite un papier, je suis sur que tu auras du succès.
> L'actualité nous a prouvé le contraire.
Je ne suis pas au courant de tout; mais peux tu me sortir UN exemple de personne ayant été condamnée uniquement sur l'utilisation du P2P et non le contenu vehiculé ?
> Même si on peut s'en sortir, on n'en ressors pas sans séquelles...
Bof. Tu sais ton voisin peut te mettre au tribunal pour tout et n'importe quoi... Je vois pas trop la différence. Au pire c'est une perte de temps et d'argent.
Les procès pour le moment servent de foire médiatique pour faire peur à la foule. Alors tu penses bien qu'ils choisissent bien leur coup ce qui diminue encore plus le risque d'avoir à te présenter.
> toutes les universités (la plupart diront nous) suivent ces recommandations. Pour elles, P2P = pirates.
C'est quand même vraiment domage que la bande passante de renater ne serve pas qu'a telecharger tout et n'importe quoi sur internet... On me fait signe dans l'oreille que "toutes" c'est non et que dans celles qui n'interdisent pas les cretins finis^w^wetudiants savent très bien pourrir la bande passante des autres et utiliser les graveurs de CD.
> GIGN ne va pas débarquer chez moi
T'es pas dans hackers et c'est pas les chinois du FBI qui vont arriver fusils mitrailleurs aà la main.
> Sachant que y'en a qui peuvent perdre leur emploi à cause d'une condamnation, est-ce raisonnable de courir de tels risques ?
Ce n'est pas par ce que les flics se pointent ou que tu es convoqué au tribunal que tu seras condamner. Il me semble que la presomption d'innocence existe toujours et qu'il va falloir ammener un peu plus de chose sur le tapis qu'un graphe montrant la BP que tu utilises pour que tu risques quelque chose.
Si tu ne fais que du légal je pense que tu n'auras aucun mal a t'en sortir.
> Et donc un commentaire venant de toi est censé être plus crédible qu'un page "au hasard" :)
Bien sur que non ! C'est simplement que c'est la norme :-)
Effectivement j'ai oublié de donner le lien je m'en excuse.
L'avantage c'est que dans la norme tu peux dire n'importe quoi tu es la norme !
> Bon ba faudra que je dise à mon prof de C que les références qu'il nous a donné sont foireuses.
Il me semble deja avoir vu passer ce lien et qu'il est pas mal. Ca ne l'empeche pas de dire au moins une connerie et si c'est la seule il est tres largement au dessus de la moyenne :-)
Depuis quand une page sortie au hasard d'internet permet de dire que c'est un bug ?
Chez moi POSIX dit ca :
=======
Early proposals required that the value of argc passed to main() be "one or greater". This was driven by the same requirement in drafts of the ISO C standard. In fact, historical implementations have passed a value of zero when no arguments are supplied to the caller of the exec functions. This requirement was removed from the ISO C standard and subsequently removed from this volume of IEEE Std 1003.1-2001 as well. The wording, in particular the use of the word should, requires a Strictly Conforming POSIX Application to pass at least one argument to the exec function, thus guaranteeing that argc be one or greater when invoked by such an application. In fact, this is good practice, since many existing applications reference argv[0] without first checking the value of argc.
=========
On notera le should !
Pour la norme C je te laisse chercher tout seul les outils pour lire du ps dans gnome sont tellement pratique qu'en 2004 y'a toujours pas la fonction "recherche"
> Pourquoi ne pas avoir fait dans la libc un lib 'secure' ?
Raisons historiques. J'etais pas la mais il me semble quand même qu'au moment de normaliser c'était déjà trop tard y'avait des implémentations pourries. Et le C c'est ultra conservateur à chaque fois qu'on risque de peter quelque chose on rajoute une tartine dans le norme pour rien casser. K&R & co n'avait pas prévu que leur langage sortirait de leur labo apparement :-)
> Dans enormément de cas c'est l'API qu'il faut remettre en cause
l'API de la libc est une sous merde. Je connais pas win32 mais je pense pas qu'il y ait plus utilisé et aussi mauvais que la libc; même dans les extensions sont attroces. Quand tu vois les socket par exemple...
Comme ca evolue pas, on se retrouve avec des extensions partout; et les uns ne veulent surtout pas des extensions des autres, c'est beaucoup plus pratique comme ca !
> pourquoi ne pas diriger les jeunes developpeurs vers des apis
mieux faites ?
Par ce que la plupart des profs de C sont completement a côté de la plaque et ne savent même pas utiliser strncpy(3) ou qu'il n'y a pas forcement de '\0'. Ca fait maintenant 3 ans que je fais du C en milieu scolaire j'ai jamais entendu prononcé une fois "buffer overflow" ou sécurité... Tu peux avoir 17 en programmant un shell qui repose sur des longjmp() dans un sighandler sans se proteger... La sécurité ca doit exister dans un monde parallèle mais pas ici.
Il est clair qu'une bonne alternative à la libc serait interessante. Je n'ai jamais mis la main sur un lib suffisament complète et documentée pour le moment par contre. Le mot de la fin, le C c'est le conservatisme à l'état pur, pour le meilleur comme pour le pire !
Et pour l'appeler il utilise la libc plutôt que de mettre ses gentils arguments dans les registres et faire ses syscalls a la main. L'enrobage de syscall c'est long par ce que tout les noyaux ont leur subtilités et ne sont pas strictement POSIX.
Pour les fonctions de plus haut niveau il est clair que dans la majorité des cas il va plus vite de les réécrire; la majorité c'est des exercices de première année de C.
Si tu veux des trucs plus net, il utilise au moins : printf, malloc, realloc avec trois grep au hasard. Il ne fourni pas d'allocateur mémoire à ma connaissance. Il n'a donc pas vocation à ne pas utiliser la libc mais simplement rajouter une couche dessus.
Bref la glib utilise la libc, libowfat utilise la libc c'etait juste ou je voulais en venir.
Au risque de te decevoir un fichier pris au hasard de libowfat
#include <unistd.h>
#include <fcntl.h>
#include "io_internal.h"
int io_appendfile(int64* d,const char* s) {
long fd=open(s,O_WRONLY|O_APPEND|O_CREAT,0600);
if (fd != -1) {
*d=fd;
return 1;
}
return 0;
}
Le but n'est pas de ne pas utiliser la libc, ca serait un travail tres/trop important de la rendre portable, mais d'éviter que le programmeur n'utilise la libc qui à un API merdique et incohérente pour des raisons historiques. Autrement la glib c'est pas mal mais il manque le reseau par exemple.
voila t'as créé la branche officielle maintenant il te faut ta branche que tu vas tagger sur la branche officielle; comprendre comment remonter les changesets et je dois en oublier.
J'ai deja vu plus simple.
Arch est extrement puissant mais faut être honnete il est très difficile à maitriser et demande un investissement de temps considérable. J'ai croisé plus d'une personne qui s'était cassé les dents à mettre le système réellement en "production" autre que pour son petit repo quoi. Et personellement j'ai passé 3 journées à avoir un truc qui marche et que je maitrise.
> Plus que pour le passage d'un noyau 2.4 à un 2.6 ?
Tu es une boite (ou un gros projet) tu as 100 developpeurs, 10 ans d'historique. Tu décides de changer, tu penses pas que la migration est énorme et que la moindre erreur va faire très mal ? Et que de toute facon ca va forcement avoir un cout au mieux les utilisateurs ne seront pas habitué au système.
> Y'a au moins une passerelle Arch <=> CVS
Tu parles de cvsv ?
"BE YE WARNED! There are severe bugs in CSCVS right now. They affect ..."
Autrement y'a tla-cvs-sync qui pourri ta base arch avec les commits cvs sans changeset
Il existe mieux ? Ca ne me semble pas être une veritable solution puisque à la base CVS et arch ne comprennent pas les mêmes notions...
[^] # Re: Quels éditeurs pour DocBook ?
Posté par ckyl . En réponse à la dépêche ooo2dbk : Générer du DocBook à partir de documents OpenOffice.org. Évalué à 0.
Par contre c'est pas fini fini et le code est malheureusement sale, pas documenté, en franglais... Je voulais essayer de contribuer un peu mais j'ai rennoncé.
Projet a surveiller tout de même
[^] # Re: Deux roues ... motorisé
Posté par ckyl . En réponse au journal Ah le skate.... Évalué à 2.
Autrement il s'amuse à passer à cote des bagnoles de police pour les insulter puis faire le con à 300km/h sur des deux voies.
Tout un programme quoi.
[^] # Re: Hum
Posté par ckyl . En réponse au journal NetBSD est bien meilleur que FreeBSD. Évalué à 3.
Les benchs veulent toujours dire quelques choses mais veulent t'ils dire quelque chose dans la vie réelle ? La principale question est la.
On a vu des tas de micro benchmark présentant des trucs pourri. Mais voila apres analyse il se trouve que le code n'était "jamais" exécuté ou que l'auteur du benchmark s'était complétement vautré.
Exemple :
http://bulk.fefe.de/scalability/fork-vs-forks.png(...)
http://bulk.fefe.de/scalability/fork.png(...)
http://www.feyrer.de/NetBSD/gmcgarry/img2.png(...)
http://www.feyrer.de/NetBSD/gmcgarry/img4.png(...)
D'après ce que disent les deux benchs ils mesurents la même chose. Pourtant sur l'un FreeBSD est en 0(1) et l'autre en 0(n). Donc soit ils ne mesurent pas la meme chose soit pas de la même manière. D'un coté NetBSD se fait later et pas de l'autre.
En regardant de plus près "The scalability benchmarks were supplied by F. von Leitner[2]." Mince c'est le même programme qui à fait les deux benchmarks ! Comme cela est-il possible ? Tu aurais une explication a me fournir ?
Il y a des tonnes d'exemples comme cela. Des dizaines de posts sur lkml qui présentait l'overhead de leur patch mais mésurait au mieux le meilleur cas au pire quelque chose qui n'avait rien a voir.
Et pour finir comme d'habitude le bench fourni des phrases vident de sens du point de vue technique pour présenter 4 graphes et l'analyse se limite a XXX roxor. Il n'y a aucun travail pour présenter ce que cela implique réellement ou expliquer le pourquoi le resultat du graphe.
Le meilleur test c'est la vie reelle et non les benchmarks ! Ca ne te fourni pas pourquoi ni où; mais de toute facon la seule chose qui t'interesse c'est qui roxor non ? Tu mets les deux dans ton environement de prod et tu vois lequel s'en sort. Le reste n'est que foutaises ou outil d'aide au developpement (seul endroit ou les micro benchmark sont utiles)
>Donc chacun retiendra ce qu'il voudra de ce journal, moi je me simplifie la vie en n'en retenant que la dernière phrase ! ;-)
Tu devrais regarder le JT de TF1 et n'en retenir que la derniere phrase sans analyse :-)
[^] # Re: éducation des utilisateurs
Posté par ckyl . En réponse au journal vulnérabilité des navigateurs mozilla. Évalué à 1.
[^] # Re: Articulations
Posté par ckyl . En réponse au journal Ah le skate.... Évalué à 2.
http://rett.free.fr/Ptit_saut.mpeg(...)
http://www.pinkbike.com/teaser/thecollective.mov(...)
http://www.pinkbike.com/modules/photo/?op=list&ptimestamp=24090(...)
Autrement pour retourner dans le genre extra terrestre non cascadeur :
http://www.ryanleech.com/videos/manifestotease1.mov(...)
http://www.ryanleech.com/videos/manifestotease2.mov(...)
http://www.ryanleech.com/videos/manifestotease3.mov(...)
http://www.ryanleech.com/videos/manifestotease4.mov(...)
Fait gaffe l'irc aussi c'est dangereux les articulations des jambes peuvent se gripper :-)
> PS : il a quand même dû s'en payer des gammelles a ses débuts...
J'ose affirmer qu'il s'en prend toujours autant :-)
Seulement certain sont fait en caoutchouc...
[^] # Re: Mot de passe utilisateur
Posté par ckyl . En réponse au journal "Venez, c'est ouvert ". Évalué à 2.
Tu sors un peu la phrase de son contexte mais l'idée est :
Si tu as le compte d'un utilisateur qui peut elever ses privilege alors tu peux acceder aux mêmes privilèges.
C'est plus ou moins compliqué. Ca va du sudo sans mot de passe, au su via empreinte digitial + mot de passe a usage unique en passant par le traditionel su + mot de passe. Mais au final on doit presque toujours pouvoir y arriver. Pour le setuid tu pourras faire ce que t'autorise le programme ou plus si faille.
> Ton "sudo" fait la résolution des alias toi ?
Non mais alias su="mysu", ou utilisation des variables environement, ou keylogger ou faille local ou.... Bref des attaques veilles comme le monde qui fonctionneront sur 99.9% des machines, le reste étant sécurisé c'est une autre histoire :-)
[^] # Re: Bien, mais
Posté par ckyl . En réponse au journal GPG contre PGP. Évalué à 2.
Dans ce cas on ne parle de la même chose et le web of trust doit etre remplacé par une architecture plus officielle type PKI avec autorite de certification et d'enregistrement. La confiance n'a rien a faire la dedans et le certificat doit etre fournis par l'état.
Que 46 personnes indiquent tu es bien colin leroy on s'en fou. Par contre que l'état te délivre le certificat est suffisant. Tu ES ou tu n'ES PAS. En aucun cas tu ES PEUT ETRE (à divers niveaux).
> mais c'est toujours mieux qu'une clé signée sauvagement parce que "je parle avec z0rro sur IRC depuis un an" donc je lui fais confiance.
Non ce n'est pas mieux.
Ce que tu as fait c'est signer la cle de z0rro (tu peux verifier que c'est bien avec lui que tu parlais). C'est le principe même. Voir la personne physique n'apporte rien surtout si tu ne l'as jamais vu. Tu ne fais pas confiance à quelqu'un en signant ca cle tu dis "Cette cle correspond au mec que je connais". A toi de ne pas signer une fausse association cle/personne mais ca, ca depasse largement le cadre de la recontre physique.
[^] # Re: 1ere ? y'a une 2eme ?
Posté par ckyl . En réponse au journal Interview de professionnels de l'informatique pour un étudiant. Évalué à 3.
Deug (2 ans)
Licence (1 an)
Maitrise (1 an)
DESS/DEA (1 an)
Maintenant
Licence (3 ans)
Master (2 ans avec branche à la deuxième année)
Donc le monsieur doit etre a sa premiere annee en fac
[^] # Re: Mot de passe utilisateur
Posté par ckyl . En réponse au journal "Venez, c'est ouvert ". Évalué à 5.
Simplement un alias sur su et voila (mais il y a plus subtile).
Ne pas se loger en root n'apporte aucune securite supplémentaire c'est un mythe. Ce que ca apporte c'est que l'on sait quel compte fait quoi rien de plus rien de moins. Je dors beaucoup mieux avec un ssh root et un root qui ne se log que depuis la console qu'avec une machine ou l'utilisateur peut se suer/sudoer... Il ne reste que deux risques, un mot de passe trop faible (c'est bien la le probleme et il est tres facile a resoudre) et une faille ssh. Pour la deuxieme y'a pas grand chose a faire de toute facon.
[^] # Re: Hmm :/
Posté par ckyl . En réponse au journal Entretient du noyau Linux. Évalué à 4.
Allez on passe sur un vrai exemple pratique qui ferait vomir n'importe quel prof de programmation du cote bien de la force.
http://fxr.watson.org/fxr/source/kernel/fork.c?v=linux-2.6.9#L904(...)
Tu me le recodes copy_process sans goto avec des fonctions qui font pas plus d'un ecran toussa ? Je suis sur que tout le monde sera tres content de ta contribution a rendre le noyau moins degeulasse puisqu'il y a toujours moyen de faire autrement
Conditions :
- le code doit marcher
- le code ne doit pas etre plus compliqué a comprendre
- le code ne doit pas etre plus de 10% plus lent
Tu as le temps que tu veux :-)
[^] # Re: Ouaip
Posté par ckyl . En réponse au journal La release de FreeBSD 5.3 est-elle une bonne cuvée ?. Évalué à 5.
Dans le sens que le système est moins reactif et qu'il bloque plus souvent les mauvais process. Ce n'est pas rare de voir que ton terminal patine pendant quelques dixièmes de seconde, C'etait excusable y'a quelques années maintenant ca fait plus tache :-)
De même la technique de swapping de FreeBSD pour les WS je la trouve bof, pour les serveurs ca se discute plus.
> C'est quoi un problème de locking?
FreeBSD a pris la direction de faire du verouillage fin. C'est utile pour le multi-processeur. Deux CPUs ne doivent pas toucher à la même structure de donnée en même temps, autrement tes informations vont etre dans etat inchorent.
FreeBSD 4 appliquait un "Giant locking" c'est a dire qu'il n'y a qu'une condition de verouillage, tu prends ton verrou en rentrant dans la routine et tu le relaches à la fin. C'est simple mais peu performant si tu fais monter le nombre de processeur.
FreeBSD a choisi de multiplier les conditions de locking, tu peux ne verouiller que ce que tu as besoin. C'est mieux en perf mais c'est plus casse geule. Et FreeBSD essuis encore un peu les platres de ce choix.
[^] # Re: Ouaip
Posté par ckyl . En réponse au journal La release de FreeBSD 5.3 est-elle une bonne cuvée ?. Évalué à 4.
Il faut aussi garder à l'esprit que Dragonfly a pour le moment l'avantage d'avoir une base d'utilisateurs très réduite ce qui permet de developper plus de fonctionalités en passant moins de temps sur le QA. Si tu regardes linux semble aussi vouloir résoudre le problème en laissant la stabilisation aux distribs puis remonté des patchs en upstream.
Mais chez FreeBSD on gère la stabilisation en interne et c'est clairement ce qui a tué la 5.3. Annoncée comme prometeuse il y a longtemps, elle devient decevante, sortie trop tardive ou pas assez parfaite. 8 mois entre 5.2.1 et 5.3 pour quel résultat du point de vu utilisateur ?
Attendons de voir si le changement de release engineering pourra faire sortir FreeBSD d'une trajectoire qui semble allez droit dans le mur tellement linux place la barre haut pour s'assurer une survie. Après c'est utilisable ce message est écrit depuis FreeBSD mais sans cette impression de peut mieux faire ca sera formidable :-)
# Ouaip
Posté par ckyl . En réponse au journal La release de FreeBSD 5.3 est-elle une bonne cuvée ?. Évalué à 7.
J'ai du abandonner FreeBSD entre 5.1 (-CURRENT cependant) et j'y suis revennu a 5.3 et pour moi le système a clairement regressé (au revoir ULE...).
La reactivité est à des années lumière de linux, toujours des problèmes de locking qui trainent un peu partout, son qui saccade en monté en charge etc. C'est domage 5- était prometeuse... Il y a 18 mois. Maintenant ca semble être un branche morte qui a trop attendu apres les testeurs, elle n'a plus grand chose d'inovante par rapport à ses concurents.
Reste beaucoup de fonctionalités interessantes, entachees par un amère gout de "pas fini".
[^] # Re: Hmm :/
Posté par ckyl . En réponse au journal Entretient du noyau Linux. Évalué à 4.
> un goto et tu comprends mieux ?
Si c'est dans deux boucles evidement.
De même pour gérer les erreurs un goto permet d'ameillorer la lisibilité en déplacant le code de gestion d'erreur en dehors du code lui même et allege la maintenance car il evite de dupliquer les actions effectuées lors de la gestion d'erreur.
Ce qui me fait marrer c'est qu'on sort toujours l'exemple du goto degeulasse qui saute dans une autre fonction pour expliquer que le goto est mauvais. Mais il me semble que personne de nos jours n'a l'intention de l'utiliser ainsi. Donc plutôt que de parler sur des cas qui n'existe pas, prouve moi qu'il y a plus elegant que le goto pour l'usage qu'on en fait dans la vie reelle.
Tu trouveras dans l'archive google du thread resumé par kerneltrap plusieurs exemples de code. Tu verras aussi que le mec qui a proposé de virer les goto a mis *UN* exemple et qu'il s'est completement vautré et que son code ne marche pas... Plus simple et plus propre on avait dit....
[^] # Re: Hmm :/
Posté par ckyl . En réponse au journal Entretient du noyau Linux. Évalué à 10.
Par ce que tu as appris a coder des applis userland ce qui n'a a peu pres rien a voir avec un noyau ?
Aller juste un exemple avec un verou, prennons Giant par hasard. Toutes les parties de ton noyau doivent pouvoir faire un lock sur Giant. Tu as la technique où il c'est une variable globale tu fais une jolie macro GIANT_REQUIRED et basta. Ou tu fais une fonction qui va à son tour faire ce que ta macro fait.
Le gain de la deuxième solution est nul et au mieux ca sera pas plus lent si la fonction est inlinée...
Je vois pas pourquoi on la virerait ! Enfin y'en a une tripotée comme ca. De même pour savoir si les peripherique doivent etre en mode verbeux ou non lors de l'initialisation. Quel avantage a une fonction "isVerbose" plutot que de tapper directement dans la variable ? Alors peut etre que tes profs t'auraient tappé dessus mais faut aussi reflechir a ce que tu gagnes reellement et ce que tu risques. Et non pas appliquer betement des principes du type "les goto c'est interdit", les variables globale c'est nul etc.
J'ai pas encore lu le papier pour pouvoir juger du chiffre annoncé dans le journal mais selon ce qui est pris en compte ca pourrait ne pas me choquer plus que ca. Aller chez FreeBSD rien que dans /kern je peux te dire qu'il y a au moins 255 variables globales.
[^] # Re: Hélas
Posté par ckyl . En réponse au journal Piratage de Linuxgraphic.org. Évalué à 10.
Faudrait arreter de voir les gentils et les mechants.
L'Hacktivsme & co c'est generalement bon pour enc*ler les mouches et passer du status de cyber cretin au cyber hero. Quelle est la difference entre rooter SCO ou linuxgraphics ? tu peux me dire ?
D'un coté ca t'arrange et pas l'autre ? Mais tu sais il existe aussi des gens de l'autre coté. Forcement ca nous, te, fait moins rire. Le gentil pirate d'SCO se transforme en gamin prepubere qui ne sait pas se servir de linux et telecharge des outils tout fait.
Faudrait arreter un peu la. Les deux peuvent être des débiles mentaux, tout comme les deux peuvent avoir fait de jolies choses du point de vu technique.
[^] # Re: Bastonnnnnnnnnn
Posté par ckyl . En réponse au journal Test des cartes NVIDIA et ATI. Évalué à 2.
[^] # Re: Oui mais....
Posté par ckyl . En réponse au journal Du bon usage de Bittorent. Évalué à 2.
Donc ca justifie que les salles machines des DEUGs (sans compte donc anonyme) servent de base de telechargement ou de lancement de DoS ? Faut bien faire quelque chose de la BP libre non ?
> Je ne suis pas certains que les étudiants utilisent des protocoles lourds autres que le P2P.
Tu oublies les scripts de reinstallation de logiciels tel eclipse & co dans les /tmp :-)
> les autres universités ne me pourrissant pas mon débit.
Non tu pourris le debit de ton "antenne". Sur les campus repartis chaque zone n'a pas accès à 2.5Gb/s. De même les reseaux locaux sont rarement gigabit.
>Deuxièmement, bloquer un traffic car il prend trop de ressources, ce n'est pas de l'incompétence, mais ça s'en rapproche
Si encore il n'y avait que du P2P légal ca serait applicable. Le fait est que 99.99% de la BP utilisé pour le P2P est illégal et viole clairement la jolie charte que tu signes en début d'année. Si tu sais comment filtrer sur le contenu écrit vite un papier, je suis sur que tu auras du succès.
> L'actualité nous a prouvé le contraire.
Je ne suis pas au courant de tout; mais peux tu me sortir UN exemple de personne ayant été condamnée uniquement sur l'utilisation du P2P et non le contenu vehiculé ?
> Même si on peut s'en sortir, on n'en ressors pas sans séquelles...
Bof. Tu sais ton voisin peut te mettre au tribunal pour tout et n'importe quoi... Je vois pas trop la différence. Au pire c'est une perte de temps et d'argent.
Les procès pour le moment servent de foire médiatique pour faire peur à la foule. Alors tu penses bien qu'ils choisissent bien leur coup ce qui diminue encore plus le risque d'avoir à te présenter.
[^] # Re: Oui mais....
Posté par ckyl . En réponse au journal Du bon usage de Bittorent. Évalué à 1.
C'est quand même vraiment domage que la bande passante de renater ne serve pas qu'a telecharger tout et n'importe quoi sur internet... On me fait signe dans l'oreille que "toutes" c'est non et que dans celles qui n'interdisent pas les cretins finis^w^wetudiants savent très bien pourrir la bande passante des autres et utiliser les graveurs de CD.
> GIGN ne va pas débarquer chez moi
T'es pas dans hackers et c'est pas les chinois du FBI qui vont arriver fusils mitrailleurs aà la main.
> Sachant que y'en a qui peuvent perdre leur emploi à cause d'une condamnation, est-ce raisonnable de courir de tels risques ?
Ce n'est pas par ce que les flics se pointent ou que tu es convoqué au tribunal que tu seras condamner. Il me semble que la presomption d'innocence existe toujours et qu'il va falloir ammener un peu plus de chose sur le tapis qu'un graphe montrant la BP que tu utilises pour que tu risques quelque chose.
Si tu ne fais que du légal je pense que tu n'auras aucun mal a t'en sortir.
[^] # Re: 13 % de « code mort »
Posté par ckyl . En réponse à la dépêche 985 bugs dans le noyau Linux. Évalué à 2.
Bien sur que non ! C'est simplement que c'est la norme :-)
Effectivement j'ai oublié de donner le lien je m'en excuse.
L'avantage c'est que dans la norme tu peux dire n'importe quoi tu es la norme !
> Bon ba faudra que je dise à mon prof de C que les références qu'il nous a donné sont foireuses.
Il me semble deja avoir vu passer ce lien et qu'il est pas mal. Ca ne l'empeche pas de dire au moins une connerie et si c'est la seule il est tres largement au dessus de la moyenne :-)
[^] # Re: 13 % de « code mort »
Posté par ckyl . En réponse à la dépêche 985 bugs dans le noyau Linux. Évalué à 5.
Chez moi POSIX dit ca :
=======
Early proposals required that the value of argc passed to main() be "one or greater". This was driven by the same requirement in drafts of the ISO C standard. In fact, historical implementations have passed a value of zero when no arguments are supplied to the caller of the exec functions. This requirement was removed from the ISO C standard and subsequently removed from this volume of IEEE Std 1003.1-2001 as well. The wording, in particular the use of the word should, requires a Strictly Conforming POSIX Application to pass at least one argument to the exec function, thus guaranteeing that argc be one or greater when invoked by such an application. In fact, this is good practice, since many existing applications reference argv[0] without first checking the value of argc.
=========
On notera le should !
Pour la norme C je te laisse chercher tout seul les outils pour lire du ps dans gnome sont tellement pratique qu'en 2004 y'a toujours pas la fonction "recherche"
[^] # Re: glib
Posté par ckyl . En réponse au journal libc et sécurité.... Évalué à 1.
Raisons historiques. J'etais pas la mais il me semble quand même qu'au moment de normaliser c'était déjà trop tard y'avait des implémentations pourries. Et le C c'est ultra conservateur à chaque fois qu'on risque de peter quelque chose on rajoute une tartine dans le norme pour rien casser. K&R & co n'avait pas prévu que leur langage sortirait de leur labo apparement :-)
> Dans enormément de cas c'est l'API qu'il faut remettre en cause
l'API de la libc est une sous merde. Je connais pas win32 mais je pense pas qu'il y ait plus utilisé et aussi mauvais que la libc; même dans les extensions sont attroces. Quand tu vois les socket par exemple...
Comme ca evolue pas, on se retrouve avec des extensions partout; et les uns ne veulent surtout pas des extensions des autres, c'est beaucoup plus pratique comme ca !
> pourquoi ne pas diriger les jeunes developpeurs vers des apis
mieux faites ?
Par ce que la plupart des profs de C sont completement a côté de la plaque et ne savent même pas utiliser strncpy(3) ou qu'il n'y a pas forcement de '\0'. Ca fait maintenant 3 ans que je fais du C en milieu scolaire j'ai jamais entendu prononcé une fois "buffer overflow" ou sécurité... Tu peux avoir 17 en programmant un shell qui repose sur des longjmp() dans un sighandler sans se proteger... La sécurité ca doit exister dans un monde parallèle mais pas ici.
Il est clair qu'une bonne alternative à la libc serait interessante. Je n'ai jamais mis la main sur un lib suffisament complète et documentée pour le moment par contre. Le mot de la fin, le C c'est le conservatisme à l'état pur, pour le meilleur comme pour le pire !
[^] # Re: glib
Posté par ckyl . En réponse au journal libc et sécurité.... Évalué à 3.
Pour les fonctions de plus haut niveau il est clair que dans la majorité des cas il va plus vite de les réécrire; la majorité c'est des exercices de première année de C.
Si tu veux des trucs plus net, il utilise au moins : printf, malloc, realloc avec trois grep au hasard. Il ne fourni pas d'allocateur mémoire à ma connaissance. Il n'a donc pas vocation à ne pas utiliser la libc mais simplement rajouter une couche dessus.
Bref la glib utilise la libc, libowfat utilise la libc c'etait juste ou je voulais en venir.
[^] # Re: glib
Posté par ckyl . En réponse au journal libc et sécurité.... Évalué à 2.
#include <unistd.h> #include <fcntl.h> #include "io_internal.h" int io_appendfile(int64* d,const char* s) { long fd=open(s,O_WRONLY|O_APPEND|O_CREAT,0600); if (fd != -1) { *d=fd; return 1; } return 0; }Le but n'est pas de ne pas utiliser la libc, ca serait un travail tres/trop important de la rendre portable, mais d'éviter que le programmeur n'utilise la libc qui à un API merdique et incohérente pour des raisons historiques. Autrement la glib c'est pas mal mais il manque le reseau par exemple.[^] # Re: Pour la licence :
Posté par ckyl . En réponse au journal Fork de CVS. Évalué à 9.
Tu ne fais que confirmer la chose. Hormis xtla qui semble bien reste 4 outils qui se battent en duel. C'est exactement ce que je disais.
> ça, c'est tout à fait subjectif ; et pour ma part, je ne le trouve pas simple du tout.
voila t'as créé la branche officielle maintenant il te faut ta branche que tu vas tagger sur la branche officielle; comprendre comment remonter les changesets et je dois en oublier.
J'ai deja vu plus simple.
Arch est extrement puissant mais faut être honnete il est très difficile à maitriser et demande un investissement de temps considérable. J'ai croisé plus d'une personne qui s'était cassé les dents à mettre le système réellement en "production" autre que pour son petit repo quoi. Et personellement j'ai passé 3 journées à avoir un truc qui marche et que je maitrise.
> Plus que pour le passage d'un noyau 2.4 à un 2.6 ?
Tu es une boite (ou un gros projet) tu as 100 developpeurs, 10 ans d'historique. Tu décides de changer, tu penses pas que la migration est énorme et que la moindre erreur va faire très mal ? Et que de toute facon ca va forcement avoir un cout au mieux les utilisateurs ne seront pas habitué au système.
> Y'a au moins une passerelle Arch <=> CVS
Tu parles de cvsv ?
"BE YE WARNED! There are severe bugs in CSCVS right now. They affect ..."
Autrement y'a tla-cvs-sync qui pourri ta base arch avec les commits cvs sans changeset
Il existe mieux ? Ca ne me semble pas être une veritable solution puisque à la base CVS et arch ne comprennent pas les mêmes notions...