> Par exemple, pour un lecteur vidéo : tu ne lances pas l'application. Tu le prends des catalogues objets
C'est bourré de problème cette approche.
L'objet doit donc contenir le décodeur, l'interface, etc...
Où tu stokes ce "truc" ? Comme se passe les mises à jour du lecteur ? Que se passe-t-il si tu changes de lecteur par défaut ? Que se passe-t-il lorsque tu copies l'objet ? Tu copies aussi le lecteur associé à l'objet ? Et si le lecteur est buggé ?
Comment rendre ça multi-plateforme ?
Cette approche doit être faite par le desktop (Gnome/KDE). Pas par l'OS.
Ne présenter que des "objets" a l'utilisateur final est très bien. Faire ça dans l'OS, non.
> (il incorpore un catalogue d'objets dont parmi eux un lecteur vidéo)
Toujours pareil. Les codecs doivent être en C. On trouve aussi les lecteurs vidéo avec VB et mono/python ont aussi la video via gstreamer. Faut pas tout mélanger. Mais si tu veux recoder gstreamer/ffmpeg en smalltalk ou java, t'es libre.
> En es tu vraiment si sûr ? Ne vois tu pas qu'autour de nous de plus en plus d'applis "lourdent" qui sortent
Tu mélanges encore tout. Ce n'est pas car il y a quelques applis lourdes que les ordinateurs sont suffisament puissant dans tous les cas. D'ailleur OOo reste trop lourd. Mozilla, ça va maintenant.
Si je regarde un DVD, ça me bouffe 50 % du cpu. C'est énorme pour une opération de "base". Si j'enregistre la tv, je bouffe 60 % de cpu en 384x288. C'est encore énorme. Et pourtant ce sont des opérations de base et en utilisant des applis optimser à mort. En java, j'ose pas imaginer l'horreur. Dans 5 ans ou 10 ans ces opérations de base seront peut-être possible.
> L'époque où seule les perfs étaient importantes
Je n'ai pas dis ça. J'ai dis que c'était important pour le bas niveau. Si le noyau ou la libc sont lents alors _TOUT_ le système est lent. Il ne sagit pas d'une ou deux applis.
> je ne voulais pas dire que les concepteurs de noyaux étaient des vieux qui ne voulaient pas changer leurs habitudes.
L'histoire montre que c'est faut (peut-être pas totalement). Linux n'a rien à voir avec un Unix classique même si c'est la même interface. Linux 2.6 n'a rien à voir avec Linux 1.2. Il y a plein de "jeune" et si tu veux bosser dessus et avancer quelles idées objets, ne te prive pas.
Les noyaux """nouveaux""" ont eu et ont encore leur chance. Mais ça ne marche pas. Il y a hurd qui arrive très péniblement et rien d'autre. Et hurd n'est pas réellement orienté objet.
> De toute façon, chacun d'entre nous à nos habitudes que l'on ne veut pas remettre en question.
Je fais du C, du C++, du php et du python. Le C a d'énormes avantages et d'énormes défauts par rapport à python ou le C++ (en fesant de l'objet).
Je répète, beaucoup de programmes C sont orientés objets. Les développeurs C ne sont pas des manches et comme moi connaissent souvent aussi des languages objets et les pratiques. Dans la pratique l'objet c'est très bien parfois et pas bien parfois. Pour en noyau, je n'en vois pas l'intérêt. Ça va ralentir pour rien ou presque.
> ils se sont bien mis à appliquer les concepts du paradigme objet
Pour Linux, c'est là ou c'est nécessaire et sans impacts sur la vitesse. Actuellement c'est pour gérer la liste des périphériques/modules/facilité. Mais tu ne trouveras pas l'objet packet IP que tu peux dériver par exemple.
> aller plus loin que nos conceptions classiques
Là ça m'énerve un peu. En quoi Linux est "classique" ?
Seulement car il n'est pas objet ?
Franchement un noyau c'est exceptionnellement complexe et doit répondre a d'énormes contraintes (performance, souplesse, nombreuse configuration, etc) Sa "modernité" ne se mesure pas à l'utilisateur de concept objet ou non.
Prend un micro noyau, enrobe le d'objet ; c'est mignon mais actuellement ce n'est pas ce qu'il y a de mieux.
> un OS vraiment objet
Utilises libg++, t'as une interface objet vers la libc et donc le noyau.
> un OS tout objet. Pourquoi pas ?
Pourquoi faire un OS (partie bas niveau) orienté objet est la "vrai" question.
Les parties basses d'un OS n'exposent pas énormément de choses. Tu peux faire une surcouche pour les fichiers, le réseau, les resources. Tu peux aussi unifier tout ça dans un objet (ala java c'est dans os.*).
Faire un objet file (ou stream/data de plus au niveau) avec les méthodes read(), write(), seek(), close() etc n'a vraiment rien de révolutionnaire et c'est déjà fait.
> Avant, oui, maintenant, avec les compétences et l'expérience actuelle, voyons ... modifions ... changeons
C'est très bien tout ça. Je code aussi en C++ (avec des _vrais_ objets) et j'aime ça.
Oui on peut faire du bas niveau en objet. Aucun problème à ça. Sauf les performances (au minimum il faut de l'édition de lien dynamique en plus) et de mémoire. A ça il faut ajouter toutes les optimisations qui ne sont plus possible si on veut rester propre. Ces optimisations sont indispensables pour les performances.
Pour un noyau et la libc la priorité c'est les performance et la taille.
Peut-être qu'un jour le niveau de performance ne sera plus prioritaire. Mais actuellement c'est loin d'être le cas.
Fais un lecteur video uniquement en java ou smalltalk ...
Fais un codec en C++ object (avec fonctions virtuels etc). Ça va ramer.
On est a une époque où le niveau de performance est important et c'est pour ça que des développeur s'arrache les cheveux avec MMX, SSE, l'assembleur, etc.
> Pourquoi "bas niveau" : parce que ce ne sont pas des développeurs objets et qu'ils sont habitués à coder d'une certaine façon avec des outils donnés
Désolé mais c'est une excuse à deux balles.
> l'habitude est notre plus grand ennemi
Nier les expériences passées est aussi un grave défaut. Prendre les développeurs du noyau pour des "vieux" qui ne veulent pas changer leur habitude n'est pas cool. Si Linux n'utilise pas le C++ ou java ..., c'est qu'il y a de bonnes raisons et je pense qui sont _beaucoup_ mieux placer pour chosir le bon language, la bonne technologie, que toi et moi. Si dans Linux il y a de l'assembleur, c'est aussi pour de bonnes raisons.
Le monde n'est pas divisé en deux :
- les vieux cons qui font du procédurale
- les jeunes dans le vent qui font de l'objet
> Maintenant, à part les couches utilisateur, je n'ai pas connu de tentatives
Il y a JavaOS (qui doit tourner sur un "vrai" OS).
En fesant des recherches sur le web, tu trouveras rapidement des noyaux orienté objet et développés en C++. Le problème est que c'est lent et donc ça ne motive pas l'arrivée de nouveaux développeurs.
Ta remarque, c'est un peu comme si tu me disait que je ne peux pas affirmer qu'un noyau en VB serait lent car il n'y a pas de noyau en VB :-)
Pour le lent et gros, je parle du bas niveau (qui doit être très très rapide et très petit).
> il y eu donc des ratés comme dans les bases de données avec O2
Postgresql (écrit en C) est aussi orienté objet (à sa façon).
Il y a 50 façons de faire de l'objet. Dès que tu utilises un descripteur dans une structure avec des pointeurs de fonction c'est un l'objet. As-tu pour autant fait un "vrai" programme objet ?
Pas sûre. Cette programmation objet de "bas niveau" est _très_ répandue (même en développement C).
Dès que quelqu'un dit "objet", les gens pensent à moderne, dans le coup. Si on dit "procédurale" les gens pensent à vieux, "has been", pourri.
Des gens qui tendent de faire un bon OS uniquement en objet, ça ne manque pas et ça fini toujours de la même façon :
- trop lourd
- trop lent
- pas souple
Faut sortir de sa bulle "conceptuelle" et revenir sur terre.
Pour le bas niveau, l'objet a largement prouvé qu'il n'était pas adapté (surtout pour des problèmes de performance et souplesse).
J'ai pas envis d'un noyau Linux en C++/java/... lent et gros uniquement pour faire hype.
> les astuces totalement indispensables mais cachees qu´on se communique normalement uniquement de gourous a gourous genre : pour compiler, c´est certes ./configure && make && make install, MAIS en plus, ils te diront eux que souvent ca se termine sur une erreur du type ("can not found caca.h") et qu´alors il faut installer le paquet libcaca-devel
C'est assez français. Ça se retrouve dans les 50 posts pour dire telle distribution est pour les newbis et telle autre pour les grands, si tu as installée une Gentoo alors t'as passé l'age de l'adolescence, etc...
Forcément, il y a une "élite" qui se forme.
De toute manière si tu aides quelqu'un avec trop de détails, t'as même pas un merci car en fait on attend de toi un truc "tout con" type "./configure".
Je ne dis pas que c'est tout le temps comme ça, mais souvent.
J'ai _beaucoup_ plus de remerciement quand j'aide d'autres personnes sur une forum étranger que sur un forum français.
Si sur un forum/mailing étranger tu dis de lire la doc "bidule", la plus part du temps ton avis est pris en considération. En France pointer une doc est limite une faute grave sur un forum.
- Linux tourne partout sauf sur le matériel Apple.
- OSX tourne nul part sauf sur le matériel Apple.
- Pour un utilisateur de Linux, il faut éviter le matériel Apple.
- Le matériel Apple n'offre pas de chois pour l'OS. C'est OSX et rien d'autre (ou presque).
> OSX remplis son rôle à merveille.
Rendre l'utilisateur dépendant du matériel Apple qui lui même ne marche bien qu'avec OSX ?
Enfermer l'utilisateur dans une solution 100 % Apple.
J'arrive pas à comprendre ce qui te dérange.
Il y a une boîte qui a des brevets et qui dit ne pas s'en servir pour attaquer le libre et toi tu fais la mou.
Ceux qui s'intéressent aux offres de Novell, propriétaires ou Open Source, doivent pouvoir arrêter leur décision d'achat sur la base de critères tels que les mérites techniques, la sécurité, la qualité de service et la valeur, et non le risque de contentieux. Novell entend continuer d'agir de manière concurrentielle sur la base des critères précités.
Ce n'est pas "ceux qui utilise ...". Novell entend vendre grace à la qualité de ces produits et non en menaçant d'attaquer un concurrent pour que tu achètes leur produit. Où il y a problème ici ?
En réalité, le risque de contrefaçon n'est pas plus grand avec les logiciels Open Source qu'avec les logiciels propriétaires.
Ils démontent un FUD MS. Ça te dérange encore ?
Par conséquent, chaque fois que nécessaire, Novell continuera d'invoquer ses différents brevets pour se défendre de toute accusation de contrefaçon relative au kernel Linux ou à tout programme Open Source inclus dans les offres de Novell.
Certe, il défende pas tout le logiciel libre mais ils utiliseront leurs brevets pour défendre le logiciel libre qu'il diffuse.
C'est bien non ?
Il est où le problème ici ?
Novell s'efforcerait notamment d'identifier les antériorités risquant d'invalider le brevet, de démontrer que le produit n'est en violation avec aucun brevet, de modifier le produit pour éviter tout risque de contrefaçon ou d'obtenir une licence auprès du propriétaire du brevet.
Là on peut voir une problème. Il n'acheterons une licence à un tière que pour eux. Mais bon, on n'a pas toujours le chois. Le brevet appartient à un propriétaire et il faut bien faire avec.
Les fournisseurs qui revendiqueront des brevets à l'encontre de clients et concurrents comme Novell le feront à leurs propres risques, avec la certitude de déclencher une procédure de défense.
Novell défendera aussi ces concurrents si ça conserne des logiciels libres qu'ils diffusent. C-à-d que les brevets Novell peuvent aider le libre dans son ensemble à se défendre.
Red Hat fait la même chose : http://www.redhat.com/legal/patent_policy.html(...)
Où tu vois problème ici ?
Ce texte est plus que satisfesant.
> Mais je ne vois nulle part Novell déclarer une opposition forte aux brevets.
Tu espérais un "patent sucks" sur un site officiel ?
Franchement, tu craches dans la soupe.
Novell indique clairement qu'ils utiliseront leurs brevets de façon défensive.
Ton point de vu serait "défendable" si les brevets logiciels n'étaient pas reconnus (notes que c'est complètement paradoxale). Malheureusement il y a les brevets logiciels et il faut faire avec. Quand je dis ça, je ne dis pas qu'il faut déposer des brevets mais qu'il faut s'armer le mieux possible pour se défendre. Utiliser des brevets pour lutter contre les brevets est au premier abord un peu "con". Mais c'est une démarche pragmatique.
Si les brevets sont reconnus, Novell utilisa ses brevets pour se défendre. C'est actuellement le _seul_ moyen pour le logiciel libre de se défendre contre les brevets (hors changer la lois, mais ce n'est pas du ressort de Novell mais des politiques et citoyens comme toi et moi). Si tu connais mieux fais nous signe.
Si Novell était pro-brevet comme tu le sous-entends, alors ils utiliseraient leurs brevets pour gagner des marchés ou faire des procès ou faire des accords "à la con" (cf Kodack vs Sun).
Si les brevets ne sont pas reconnus, Novell est content. Par définition il n'auront pas à utiliser leurs brevets.
Si on attaque pas Novell (ce qui n'est pas du ressord de Novell) alors Novell se défends avec les brevets.
Novell est contre la reconnaissance des brevets en Europe.
Où tu vois une attitude pro-brevet ?
On peut être contre les armes et paradoxalement en avoir par nécessité car d'_autres_ ont des armes et il faut bien faire avec ça. À nous, d'invalider les armes (brevets) au niveau législatif.
LD_ASSUME_KERNEL sur un système NPTL permet d'utiliser linuxthread (donc de ne pas utiliser NPTL). C'est pour ça qu'il faut l'utiliser pour des vieux programmes qui n'ont pas été compilé avec NPTL.
Certe, c'est lié à la glibc. Mais si tu vires NPTL de la glibc de ton système, les autres programmes ne marchent pas ou ne profitent pas des amélioration de NPTL.
Le problème est qu'il y a une implémentation thread par défaut. Sur RHEL 3 c'est NPTL mais linuxthread (l'ancien) est toujours là ! Suffit d'utiliser LD_ASSUME_KERNEL.
Bref, le bug est souvent entre l'écran et la chaise.
Relis ton post initiale :
- "Moi, j'ai mis une dropline sur le pc de mon épouse et j'en suis satisfait."
Si on ne part pas de préjugés sexistes cette phrase est totalement sans intérêt dans le contexte de la discussion sur PAM.
Pour ton info, dropline utilise PAM donc je ne vois pas le rapport avec les raisons du mainteneur de Slack de na pas utiliser PAM.
Donc qu'as-tu voulu dire ?
Que dropline c'est bien et fait ton/votre bonheur ?
J'en suis enchanté.
> Elle l'a lu puisque j'ai rédigé mes réponses devant elle.
On connait pas la distribution ni le programme ni la version de glibc....
> export LD-ASSUME_KERNEL=2.4.9
Tu as probablement un programme qui utilise linuxthread alors que tu utilises un noyau/libc avec NPTL.
> où je peux trouver ce GLIBC_2.0 !
Dans glibc.
glibc est versionné (caractéristique du format elf) pour supporter plusieurs versions de fonction. C'est entre autre ce qui est fait avec LD_ASSUME_KERNEL qui te permet de choisir linuxthread à la place de NTPL.
> t'as pas l'air de comprendre que si j'ai installé un truc sur le pc de mon épouse, c'est parce qu'elle ne savait pas le faire
T'as pas l'air de ne pas comprendre que ton préjugé que tout le monde accepte comme acquis que si la personne consernée est une femme, alors forcément elle ne sait pas ou ne veux pas installer/administer une bécane est sexiste.
Si je lis :
- ma femme est contente avec Linux
je ne conclus rien sur la facilité d'utilisation de Linux.
Mais toi tu penses que la phrase précédente va être interprété par tout le monde comme ça :
- ma femme qui n'est pas très douée en informatique est contente avec Linux qui est suffisament simple pour elle.
C'est définitivement sexiste.
> t'es bizarre.
T'es sexiste.
> tu fais passer les féministes pour des hystériques
Dis que tu as oublié de préciser dans ton post initiale que ton épouse ne sait pas (ou ne veux pas) administrer une bécane au-lieu de défendre des propos clairement sexiste. C'est beaucoup plus simple que de ramer "hytériquement" comme tu le fais actuellement.
Tout le monde peut se tromper (et j'ai surement déjà tenu des propos sexistes sans le faire exprès). J'accepte parfaitement ce type d'erreur si elle est reconnue. Je deviens "hystérique" quand quelqu'un ne se rend pas compte des propos sexiste qu'il tient. Que cette personne soit sexiste ou non.
> Après on s'étonne que rien ne bouge
Tu penses qu'en laissant passer des propos sexistes ça va changer ?
Pas moi.
Au fait, laisses ta femme lire ce thread et qu'elle dise ce qu'elle en pense. C'est la première concernée.
Posté par Ayrton .
En réponse au journal KDE 3.3.1.
Évalué à 2.
Je ne sais pas ce qu'il en est pour Mandrake. Mais FC3 (en phase de test actuellement) a KDE 3.3.0 (et sûrement 3.3.1 dans quelques jours) et donc une grosse partie du boulot était déjà faite via FC3.
Le "portage" vers FC2 est une initiative personnelle. Rien de concret ne dit que cela sera renouvellé.
Que ça soit "non OpenSource" ne me dérange pas. C'est au logiciel libre de faire sa place par ses qualités et de se battre "loyalement" contre le logiciel "non OpenSource". Mais les brevets (et EUCD) en accordant des monopoles (que le logiciel libre par définition ne peut pas avoir) ne permettent pas ça et donc j'y suis totalement opposé.
[^] # Re: Hmhm
Posté par Ayrton . En réponse au journal j'ai un rêve .... Évalué à 1.
C'est bourré de problème cette approche.
L'objet doit donc contenir le décodeur, l'interface, etc...
Où tu stokes ce "truc" ? Comme se passe les mises à jour du lecteur ? Que se passe-t-il si tu changes de lecteur par défaut ? Que se passe-t-il lorsque tu copies l'objet ? Tu copies aussi le lecteur associé à l'objet ? Et si le lecteur est buggé ?
Comment rendre ça multi-plateforme ?
Cette approche doit être faite par le desktop (Gnome/KDE). Pas par l'OS.
Ne présenter que des "objets" a l'utilisateur final est très bien. Faire ça dans l'OS, non.
[^] # Re: J'en ai rèvé^Umarre
Posté par Ayrton . En réponse au journal j'ai un rêve .... Évalué à 4.
Toujours pareil. Les codecs doivent être en C. On trouve aussi les lecteurs vidéo avec VB et mono/python ont aussi la video via gstreamer. Faut pas tout mélanger. Mais si tu veux recoder gstreamer/ffmpeg en smalltalk ou java, t'es libre.
> En es tu vraiment si sûr ? Ne vois tu pas qu'autour de nous de plus en plus d'applis "lourdent" qui sortent
Tu mélanges encore tout. Ce n'est pas car il y a quelques applis lourdes que les ordinateurs sont suffisament puissant dans tous les cas. D'ailleur OOo reste trop lourd. Mozilla, ça va maintenant.
Si je regarde un DVD, ça me bouffe 50 % du cpu. C'est énorme pour une opération de "base". Si j'enregistre la tv, je bouffe 60 % de cpu en 384x288. C'est encore énorme. Et pourtant ce sont des opérations de base et en utilisant des applis optimser à mort. En java, j'ose pas imaginer l'horreur. Dans 5 ans ou 10 ans ces opérations de base seront peut-être possible.
> L'époque où seule les perfs étaient importantes
Je n'ai pas dis ça. J'ai dis que c'était important pour le bas niveau. Si le noyau ou la libc sont lents alors _TOUT_ le système est lent. Il ne sagit pas d'une ou deux applis.
> je ne voulais pas dire que les concepteurs de noyaux étaient des vieux qui ne voulaient pas changer leurs habitudes.
L'histoire montre que c'est faut (peut-être pas totalement). Linux n'a rien à voir avec un Unix classique même si c'est la même interface. Linux 2.6 n'a rien à voir avec Linux 1.2. Il y a plein de "jeune" et si tu veux bosser dessus et avancer quelles idées objets, ne te prive pas.
Les noyaux """nouveaux""" ont eu et ont encore leur chance. Mais ça ne marche pas. Il y a hurd qui arrive très péniblement et rien d'autre. Et hurd n'est pas réellement orienté objet.
> De toute façon, chacun d'entre nous à nos habitudes que l'on ne veut pas remettre en question.
Je fais du C, du C++, du php et du python. Le C a d'énormes avantages et d'énormes défauts par rapport à python ou le C++ (en fesant de l'objet).
Je répète, beaucoup de programmes C sont orientés objets. Les développeurs C ne sont pas des manches et comme moi connaissent souvent aussi des languages objets et les pratiques. Dans la pratique l'objet c'est très bien parfois et pas bien parfois. Pour en noyau, je n'en vois pas l'intérêt. Ça va ralentir pour rien ou presque.
> ils se sont bien mis à appliquer les concepts du paradigme objet
Pour Linux, c'est là ou c'est nécessaire et sans impacts sur la vitesse. Actuellement c'est pour gérer la liste des périphériques/modules/facilité. Mais tu ne trouveras pas l'objet packet IP que tu peux dériver par exemple.
> aller plus loin que nos conceptions classiques
Là ça m'énerve un peu. En quoi Linux est "classique" ?
Seulement car il n'est pas objet ?
Franchement un noyau c'est exceptionnellement complexe et doit répondre a d'énormes contraintes (performance, souplesse, nombreuse configuration, etc) Sa "modernité" ne se mesure pas à l'utilisateur de concept objet ou non.
Prend un micro noyau, enrobe le d'objet ; c'est mignon mais actuellement ce n'est pas ce qu'il y a de mieux.
> un OS vraiment objet
Utilises libg++, t'as une interface objet vers la libc et donc le noyau.
> un OS tout objet. Pourquoi pas ?
Pourquoi faire un OS (partie bas niveau) orienté objet est la "vrai" question.
Les parties basses d'un OS n'exposent pas énormément de choses. Tu peux faire une surcouche pour les fichiers, le réseau, les resources. Tu peux aussi unifier tout ça dans un objet (ala java c'est dans os.*).
Faire un objet file (ou stream/data de plus au niveau) avec les méthodes read(), write(), seek(), close() etc n'a vraiment rien de révolutionnaire et c'est déjà fait.
[^] # Re: J'en ai rèvé^Umarre
Posté par Ayrton . En réponse au journal j'ai un rêve .... Évalué à 1.
C'est très bien tout ça. Je code aussi en C++ (avec des _vrais_ objets) et j'aime ça.
Oui on peut faire du bas niveau en objet. Aucun problème à ça. Sauf les performances (au minimum il faut de l'édition de lien dynamique en plus) et de mémoire. A ça il faut ajouter toutes les optimisations qui ne sont plus possible si on veut rester propre. Ces optimisations sont indispensables pour les performances.
Pour un noyau et la libc la priorité c'est les performance et la taille.
Peut-être qu'un jour le niveau de performance ne sera plus prioritaire. Mais actuellement c'est loin d'être le cas.
Fais un lecteur video uniquement en java ou smalltalk ...
Fais un codec en C++ object (avec fonctions virtuels etc). Ça va ramer.
On est a une époque où le niveau de performance est important et c'est pour ça que des développeur s'arrache les cheveux avec MMX, SSE, l'assembleur, etc.
> Pourquoi "bas niveau" : parce que ce ne sont pas des développeurs objets et qu'ils sont habitués à coder d'une certaine façon avec des outils donnés
Désolé mais c'est une excuse à deux balles.
> l'habitude est notre plus grand ennemi
Nier les expériences passées est aussi un grave défaut. Prendre les développeurs du noyau pour des "vieux" qui ne veulent pas changer leur habitude n'est pas cool. Si Linux n'utilise pas le C++ ou java ..., c'est qu'il y a de bonnes raisons et je pense qui sont _beaucoup_ mieux placer pour chosir le bon language, la bonne technologie, que toi et moi. Si dans Linux il y a de l'assembleur, c'est aussi pour de bonnes raisons.
Le monde n'est pas divisé en deux :
- les vieux cons qui font du procédurale
- les jeunes dans le vent qui font de l'objet
[^] # Re: J'en ai rèvé^Umarre
Posté par Ayrton . En réponse au journal j'ai un rêve .... Évalué à 1.
[^] # Re: J'en ai rèvé^Umarre
Posté par Ayrton . En réponse au journal j'ai un rêve .... Évalué à -2.
Il y a JavaOS (qui doit tourner sur un "vrai" OS).
En fesant des recherches sur le web, tu trouveras rapidement des noyaux orienté objet et développés en C++. Le problème est que c'est lent et donc ça ne motive pas l'arrivée de nouveaux développeurs.
Ta remarque, c'est un peu comme si tu me disait que je ne peux pas affirmer qu'un noyau en VB serait lent car il n'y a pas de noyau en VB :-)
[^] # Re: J'en ai rèvé^Umarre
Posté par Ayrton . En réponse au journal j'ai un rêve .... Évalué à 1.
> il y eu donc des ratés comme dans les bases de données avec O2
Postgresql (écrit en C) est aussi orienté objet (à sa façon).
Il y a 50 façons de faire de l'objet. Dès que tu utilises un descripteur dans une structure avec des pointeurs de fonction c'est un l'objet. As-tu pour autant fait un "vrai" programme objet ?
Pas sûre. Cette programmation objet de "bas niveau" est _très_ répandue (même en développement C).
[^] # Re: J'en ai rèvé^Umarre
Posté par Ayrton . En réponse au journal j'ai un rêve .... Évalué à 2.
http://lwn.net/Articles/51437/(...)
http://lwn.net/Articles/52621/(...)
http://lwn.net/Articles/54651/(...)
http://lwn.net/Articles/55847/(...)
C'est très light (kobject, pas les articles :-)).
# J'en ai rèvé^Umarre
Posté par Ayrton . En réponse au journal j'ai un rêve .... Évalué à 6.
Des gens qui tendent de faire un bon OS uniquement en objet, ça ne manque pas et ça fini toujours de la même façon :
- trop lourd
- trop lent
- pas souple
Faut sortir de sa bulle "conceptuelle" et revenir sur terre.
Pour le bas niveau, l'objet a largement prouvé qu'il n'était pas adapté (surtout pour des problèmes de performance et souplesse).
J'ai pas envis d'un noyau Linux en C++/java/... lent et gros uniquement pour faire hype.
[^] # Re: C'est tout jeune mais déjà bien.
Posté par Ayrton . En réponse au journal Test d'Ubuntu. Évalué à -1.
[^] # Re: C'est tout jeune mais déjà bien.
Posté par Ayrton . En réponse au journal Test d'Ubuntu. Évalué à -1.
Tu utilises IPOT ?
FC3 n'est pas encore sorti.
[^] # Re: Moi je vous comprend pas trop ??????????
Posté par Ayrton . En réponse au journal Petition Mandrake: une réponse. Évalué à 1.
Arrêtez avec les distributions pour débutant ou élite.
Linus Torvalds utilisait SuSE et ce n'est pas un débutant.
[^] # Re: Moi je vous comprend pas trop ??????????
Posté par Ayrton . En réponse au journal Petition Mandrake: une réponse. Évalué à 2.
C'est assez français. Ça se retrouve dans les 50 posts pour dire telle distribution est pour les newbis et telle autre pour les grands, si tu as installée une Gentoo alors t'as passé l'age de l'adolescence, etc...
Forcément, il y a une "élite" qui se forme.
De toute manière si tu aides quelqu'un avec trop de détails, t'as même pas un merci car en fait on attend de toi un truc "tout con" type "./configure".
Je ne dis pas que c'est tout le temps comme ça, mais souvent.
J'ai _beaucoup_ plus de remerciement quand j'aide d'autres personnes sur une forum étranger que sur un forum français.
Si sur un forum/mailing étranger tu dis de lire la doc "bidule", la plus part du temps ton avis est pris en considération. En France pointer une doc est limite une faute grave sur un forum.
PS : libcaca exite ! Ça m'a scié.
[^] # Re: Portables
Posté par Ayrton . En réponse à la dépêche Yellow Dog Linux 4.0. Évalué à 0.
- linux sucks car il marche mal sur le matériel Apple
- OSX roxor car il marche bien sur le matériel Apple
Je peux dire que OSX sucks grave sur i386, sparc, AMD64, etc...
[^] # Re: Qui a dit...
Posté par Ayrton . En réponse à la dépêche Yellow Dog Linux 4.0. Évalué à 2.
Aurox, Cobind Desktop, LormaLINUX, KRUD, MostlyLinux, Resala Linux, ADIOS, K12LTSP sont aussi basées sur FC.
J'en oublie surement.
[^] # Re: Différences ?
Posté par Ayrton . En réponse à la dépêche Dropline Gnome 2.8 disponible (depuis le 07/10/2004). Évalué à 0.
Oublions ce thread.
[^] # Re: Portables
Posté par Ayrton . En réponse à la dépêche Yellow Dog Linux 4.0. Évalué à 0.
- OSX tourne nul part sauf sur le matériel Apple.
- Pour un utilisateur de Linux, il faut éviter le matériel Apple.
- Le matériel Apple n'offre pas de chois pour l'OS. C'est OSX et rien d'autre (ou presque).
> OSX remplis son rôle à merveille.
Rendre l'utilisateur dépendant du matériel Apple qui lui même ne marche bien qu'avec OSX ?
Enfermer l'utilisateur dans une solution 100 % Apple.
# coquille
Posté par Ayrton . En réponse à la dépêche Yellow Dog Linux 4.0. Évalué à 1.
Ça doit être 6.7 . X.org 6.6 n'existe pas.
L'erreur (il me semble) est aussi sur la page de "Présentation".
Si quelqu'un sait où on peut mettre la main sur les sources, la coquille pourrait être confirmée ou non.
[^] # Re: mais bien sûr
Posté par Ayrton . En réponse au journal Novell et les brevets. Évalué à 0.
Il y a une boîte qui a des brevets et qui dit ne pas s'en servir pour attaquer le libre et toi tu fais la mou.
> http://www.novell.com/fr-fr/company/policies/patent/(...)
Ceux qui s'intéressent aux offres de Novell, propriétaires ou Open Source, doivent pouvoir arrêter leur décision d'achat sur la base de critères tels que les mérites techniques, la sécurité, la qualité de service et la valeur, et non le risque de contentieux. Novell entend continuer d'agir de manière concurrentielle sur la base des critères précités.
Ce n'est pas "ceux qui utilise ...". Novell entend vendre grace à la qualité de ces produits et non en menaçant d'attaquer un concurrent pour que tu achètes leur produit. Où il y a problème ici ?
En réalité, le risque de contrefaçon n'est pas plus grand avec les logiciels Open Source qu'avec les logiciels propriétaires.
Ils démontent un FUD MS. Ça te dérange encore ?
Par conséquent, chaque fois que nécessaire, Novell continuera d'invoquer ses différents brevets pour se défendre de toute accusation de contrefaçon relative au kernel Linux ou à tout programme Open Source inclus dans les offres de Novell.
Certe, il défende pas tout le logiciel libre mais ils utiliseront leurs brevets pour défendre le logiciel libre qu'il diffuse.
C'est bien non ?
Il est où le problème ici ?
Novell s'efforcerait notamment d'identifier les antériorités risquant d'invalider le brevet, de démontrer que le produit n'est en violation avec aucun brevet, de modifier le produit pour éviter tout risque de contrefaçon ou d'obtenir une licence auprès du propriétaire du brevet.
Là on peut voir une problème. Il n'acheterons une licence à un tière que pour eux. Mais bon, on n'a pas toujours le chois. Le brevet appartient à un propriétaire et il faut bien faire avec.
Les fournisseurs qui revendiqueront des brevets à l'encontre de clients et concurrents comme Novell le feront à leurs propres risques, avec la certitude de déclencher une procédure de défense.
Novell défendera aussi ces concurrents si ça conserne des logiciels libres qu'ils diffusent. C-à-d que les brevets Novell peuvent aider le libre dans son ensemble à se défendre.
Red Hat fait la même chose :
http://www.redhat.com/legal/patent_policy.html(...)
Où tu vois problème ici ?
Ce texte est plus que satisfesant.
> Mais je ne vois nulle part Novell déclarer une opposition forte aux brevets.
Tu espérais un "patent sucks" sur un site officiel ?
Franchement, tu craches dans la soupe.
Novell indique clairement qu'ils utiliseront leurs brevets de façon défensive.
Ton point de vu serait "défendable" si les brevets logiciels n'étaient pas reconnus (notes que c'est complètement paradoxale). Malheureusement il y a les brevets logiciels et il faut faire avec. Quand je dis ça, je ne dis pas qu'il faut déposer des brevets mais qu'il faut s'armer le mieux possible pour se défendre. Utiliser des brevets pour lutter contre les brevets est au premier abord un peu "con". Mais c'est une démarche pragmatique.
Si les brevets sont reconnus, Novell utilisa ses brevets pour se défendre. C'est actuellement le _seul_ moyen pour le logiciel libre de se défendre contre les brevets (hors changer la lois, mais ce n'est pas du ressort de Novell mais des politiques et citoyens comme toi et moi). Si tu connais mieux fais nous signe.
Si Novell était pro-brevet comme tu le sous-entends, alors ils utiliseraient leurs brevets pour gagner des marchés ou faire des procès ou faire des accords "à la con" (cf Kodack vs Sun).
Si les brevets ne sont pas reconnus, Novell est content. Par définition il n'auront pas à utiliser leurs brevets.
Si on attaque pas Novell (ce qui n'est pas du ressord de Novell) alors Novell se défends avec les brevets.
Novell est contre la reconnaissance des brevets en Europe.
Où tu vois une attitude pro-brevet ?
On peut être contre les armes et paradoxalement en avoir par nécessité car d'_autres_ ont des armes et il faut bien faire avec ça. À nous, d'invalider les armes (brevets) au niveau législatif.
[^] # Re: redhat ?
Posté par Ayrton . En réponse au message une équivalence de GLIBC_2.0. Évalué à 0.
LD_ASSUME_KERNEL sur un système NPTL permet d'utiliser linuxthread (donc de ne pas utiliser NPTL). C'est pour ça qu'il faut l'utiliser pour des vieux programmes qui n'ont pas été compilé avec NPTL.
Certe, c'est lié à la glibc. Mais si tu vires NPTL de la glibc de ton système, les autres programmes ne marchent pas ou ne profitent pas des amélioration de NPTL.
Le problème est qu'il y a une implémentation thread par défaut. Sur RHEL 3 c'est NPTL mais linuxthread (l'ancien) est toujours là ! Suffit d'utiliser LD_ASSUME_KERNEL.
Bref, le bug est souvent entre l'écran et la chaise.
[^] # Re: Différences ?
Posté par Ayrton . En réponse à la dépêche Dropline Gnome 2.8 disponible (depuis le 07/10/2004). Évalué à 0.
- "Moi, j'ai mis une dropline sur le pc de mon épouse et j'en suis satisfait."
Si on ne part pas de préjugés sexistes cette phrase est totalement sans intérêt dans le contexte de la discussion sur PAM.
Pour ton info, dropline utilise PAM donc je ne vois pas le rapport avec les raisons du mainteneur de Slack de na pas utiliser PAM.
Donc qu'as-tu voulu dire ?
Que dropline c'est bien et fait ton/votre bonheur ?
J'en suis enchanté.
> Elle l'a lu puisque j'ai rédigé mes réponses devant elle.
Mouaifff...
> n'aimons pas qu'on l'appelle "ma femme"
Désolé.
[^] # Re: petite précision
Posté par Ayrton . En réponse au message une équivalence de GLIBC_2.0. Évalué à 0.
http://www.gnu.org/software/libc/(...)
La doc :
http://www.gnu.org/software/libc/manual/html_node/index.html(...)
Puisque tu ne veux rien dire de ton problème (on ne connais toujours pas le programme qui coince), bon chance.
# C'est tout ?
Posté par Ayrton . En réponse au message une équivalence de GLIBC_2.0. Évalué à -1.
> export LD-ASSUME_KERNEL=2.4.9
Tu as probablement un programme qui utilise linuxthread alors que tu utilises un noyau/libc avec NPTL.
> où je peux trouver ce GLIBC_2.0 !
Dans glibc.
glibc est versionné (caractéristique du format elf) pour supporter plusieurs versions de fonction. C'est entre autre ce qui est fait avec LD_ASSUME_KERNEL qui te permet de choisir linuxthread à la place de NTPL.
[^] # Re: Différences ?
Posté par Ayrton . En réponse à la dépêche Dropline Gnome 2.8 disponible (depuis le 07/10/2004). Évalué à -2.
T'as pas l'air de ne pas comprendre que ton préjugé que tout le monde accepte comme acquis que si la personne consernée est une femme, alors forcément elle ne sait pas ou ne veux pas installer/administer une bécane est sexiste.
Si je lis :
- ma femme est contente avec Linux
je ne conclus rien sur la facilité d'utilisation de Linux.
Mais toi tu penses que la phrase précédente va être interprété par tout le monde comme ça :
- ma femme qui n'est pas très douée en informatique est contente avec Linux qui est suffisament simple pour elle.
C'est définitivement sexiste.
> t'es bizarre.
T'es sexiste.
> tu fais passer les féministes pour des hystériques
Dis que tu as oublié de préciser dans ton post initiale que ton épouse ne sait pas (ou ne veux pas) administrer une bécane au-lieu de défendre des propos clairement sexiste. C'est beaucoup plus simple que de ramer "hytériquement" comme tu le fais actuellement.
Tout le monde peut se tromper (et j'ai surement déjà tenu des propos sexistes sans le faire exprès). J'accepte parfaitement ce type d'erreur si elle est reconnue. Je deviens "hystérique" quand quelqu'un ne se rend pas compte des propos sexiste qu'il tient. Que cette personne soit sexiste ou non.
> Après on s'étonne que rien ne bouge
Tu penses qu'en laissant passer des propos sexistes ça va changer ?
Pas moi.
Au fait, laisses ta femme lire ce thread et qu'elle dise ce qu'elle en pense. C'est la première concernée.
[^] # Re: Sou-ssé
Posté par Ayrton . En réponse au journal KDE 3.3.1. Évalué à 2.
Le "portage" vers FC2 est une initiative personnelle. Rien de concret ne dit que cela sera renouvellé.
[^] # Re: mais bien sûr
Posté par Ayrton . En réponse au journal Novell et les brevets. Évalué à 0.
Que ça soit "non OpenSource" ne me dérange pas. C'est au logiciel libre de faire sa place par ses qualités et de se battre "loyalement" contre le logiciel "non OpenSource". Mais les brevets (et EUCD) en accordant des monopoles (que le logiciel libre par définition ne peut pas avoir) ne permettent pas ça et donc j'y suis totalement opposé.