Est-ce qu'ils ont un objectif pour les performances de cette librairie, comparativement à la XLib ?
Pas vraiment, l'idée générale est que cela devrait être globalement très bénéfique.
Je m'explique, si il y a une seule application sur le serveur X, alors le lock exclusif n'est pas vraiment génant, si elle est non threadée alors le lock est même plutot bénéfique en termes de perfs (pas besoin de mutexs, de vérifier les conditions de course etc.). Par contre dans a peu près tous les autres cas XCB devrait permettre au serveur X de s'occupper de plusieurs applications en même temps, pas besoin par exemple d'attendre d'avoir renvoyé l'intégralité d'un bitmap a une fenetre (fausse transparence entre autre) pour pouvoir afficher du texte dans une autre.
L'exemple donné dans le texte n'est pas le bon.
On rencontre la vrai limite des droits Unix dans le cas suivant :
On veut un groupe en execution seule sur un repertoire (les utilisateurs) et un groupe en lecture/ecriture/execution (les admins du programe). Ben là ca devient complexe. Bonjour la floraison de SetUID et de SetGID....
Si dérrière il faut un groupe en lecture/execution (pour l'audit) et un groupe en lecture seule (pour les back-ups) c'est carrément la fête au village.
La logique de la protection des droits est celle du logiciel propriétaire (« ce logiciel m'appartient, j'ai des droits, je les protège »).
Et la GPL ? Tu crois que le fait de pouvoir récupérer toutes les modifs faites a ton source sur tous les programmes distribués qui l'utilisent comme base ca n'est pas un droit ?
Le fait que tu restes dans la liste des auteurs, que tu puisses te défendre contre des gens qui ne respectent la GPL attenante a ton code etc. C'est des droits !
Une license sert a donner des droits et a en garder. Et en GPL on garde pas mal de droit et on impose pas mal de devoir aux contributeurs...
Oui, d'accord, mais, dans le libre, cela pose un autre problème. Les licenses libres sont justement conçues pour permettre l'échange de code entre divers projets, pour ne pas avoir à réinventer la roue à chaque fois.
L'interet principal d'une licence est de protéger ses droits. L'auteur choisit la licence qui lui convient le mieux et y apporte éventuellement des modifications/corrections pour avoir exactement ce qu'il veut.
L'échange de code entre les projets, même si il est philosophiquement la pierre d'angle du libre, n'est vis a vis de la license qu'une des conditions d'utilisation. Un auteur qui n'utilise pas telle ou telle licence peut tomber dans deux cas différents :
- a) il s'en fout ou il n'a jamais entendu parler de la licence en question, dans ce cas là avec un simple echange d'emails on arrive souvent a obtenir le code sous une licence qui convient mieux. A partir de là on n'a pas a réinventer la roue.
- b) Pour des raisons qui le regarde il ne veut pas de la license qui vous arrangerait vous. Dans ce cas là, comme c'est lui l'auteur du code, c'est lui qui décide. Mais a moins de tomber sur une grosse boite qui joue a faire du libre pour pouvoir apater le badaud, il sera très sans doute prêt a vous aider a construire une alternative a son code et a vous fournir moults conseils et corrections (sauf le projet XFree bien sur, mais c'est un peu l'exception qui confirme la règle.)
Tiens d'ailleurs : chiche d'envoyer un email a RMS en disant que l'on est en train de faire un emacs like en C++ sous licence BSD et d elui demander son point de vue là dessus ? Ca pourrait être drole.
Kha
P.S Hors sujet : en ce qui concerne le droit d'écrire, il faut savoir que passer un texte en licence libre de façon porpre en France est une opération relativement complexe, qui implique entre autre de déposer ses droits avant de renoncer a une partie d'entre eux (compliqué encore par le fait que comme le texte est paru en avant première sur DLFP, il me faudrait un papier des responsables du site disant qu'ils ne sont pas mes éditeurs et que le texte m'appartient pleinement.). Je ne me sens pas de faire çà la maintenant, tout de suite. Mais patience, a défaut de licence libre il y aura peut-être une surprise.
Autant je comprends que la multiplication des licenses puisse agacer les différents leaders du libre qui dans un élan d'humilité exemplaire c'étaient imaginés que l'esemble des contributeurs du libre allaient faire comme ils le disaient parceque c'étaient eux qui le disaient. Autant invoquer le coté pénible et confus pour l'utilisateur final est passablement risible.
Sur un système propriétaire (au hasard windows) rien que les outils basiques sont souvent soumis a bien plus que 52 licences.
Faut pas révé, entre la license originale, celle de la mise a jour, celles des patchs, celle du lecteur audio-vidéo, celle du logiciel de messagerie, celle du navigateur, celle du logiciel de messagerie instantanée etc. Un client ou prospect sera supposé avoir lu, compris et accepté bien plus de 52 licences subtilement différentes entre le moment ou il insère le CD d'installation dans sa machine et le moment ou il aura fini l'ensemble des mises a jour.
Il ne lui restera ensuite qu'à enchainer sur l'installation de MS Office et du pack internet fourni avec son abonnement. Avant de finir par les outils dont il a besoin professionellement et qui, si ils sont propriétaires, ne manqueront pas d'avoir leur propre license sur une ou plusieurs pages.
Qu'on se le dise 52 licences c'est très peu vu l'ensemble des produits qu'elles recouvrent.
C'est même volontairement un peu caricatural. Mais d'un autre coté c'est supposé avoir lieu dans au moins 100 ans. Et puis comme je voulais un texte assez court, pas assez de talent pour faire une oeuvre majeure. Il y a un certain nombre de raccourcis et d'incohérences dans ce texte. (Mais je ne les dirais pas, a vous de trouver.)
Il existe un grand nombre de cartes 8139. Le mieux étant de les essayer les unes dérrière les autres.
Les modules différents peuvent être :
n2K-PCI pour les 8139 tout court et certains board A/B
8139CP pour les 8139c est certaines exotiques
8139too pour les cartes un peu plus récentes.
8139too ou b44 pour les realtek respinés par broadcom (avec les b44 si vous vous retrouvez bloqué a 1Ghz alors c'est qui vous faut les bcm440 dispo en GPL sur le site de broadcom.)
Les 8139 sont très répendue, mais les versions un peu plus moderne sont parfois problématiques.
Personellement dès que je peux je mets 30Euros de plus et je prend de l'Intel. Mais ca n'engage que moi.
tu ne peux *pas* modifier iexplore.exe: après qques secondes il est automatiquement restauré par l'OS
Ca se contourne relativement facilement. Soit en bootant en mode sans echec, soit en le remplacant pendant la boot phase de windows. Personellement le nombre de truc qui se restaurent automatiquement que j'ai giclé de mes Windows XP (Messenger, Outlook, MediaPlayer pour ne citer que les plus célèbres).
Par contre l'autorestore est une fonctionnalité géniale pour les auteurs de virus... Certains spywares s'en servaient avant le SP1, je ne sais pas si c'est encore valable.
Sauf que sous Windows XP Familial (donc celui vendu en grande surface) le compte Administrateur existe mais n'est pas utilisable.
Oh que si il est utilisable. Malheureusement, parceque 99 fois sur 100 son mot de passe est initialisé a vide.
Pour récuperer les droits sur votre compte admin, pressez F8 pendant le boot de Windows XP, la mire vous présentera alors l'administrateur parmis les options possibles. Vous pourrez alors vérifier que son mot de passe est bien vide et luid onner le mot de passe de votre choix. Sinon vous pouvez le changer depuis n'importe quel compte avec les droits admin sur la machine. Pendant que vous y êtes pensez a le renommer aussi.
Si vous désirez l'utiliser en session normale (donc hors mode sans echec) il vous faudra desactiver la page d'acceuil login et revenir a la boite de dialogue "old school".
Il est bien entendu déconseillé d'utiliser ce compte là pour travailler sur son ordinateur.
[x] Souvent, parceque des fois je me prend pour un kernel hacker (succes tres modere jusque la...)
[x] Souvent, parceque j'ai une partition qui me sert a tester toutes les distribs qui me passent sous la main (et a faire des bugs reports)
[x] Souvent, parceque je teste aussi des emulateurs (Bochs et PearPC, pour ne pas les nommer)
[x] Souvent parceque j'essaye de creer ma propre distrib (En plus c'est du SE_Linux sur crypto loop, une erreur -> poubelle)
[x] Souvent parceque j'essaye de creer une lib de memoire partagee, avec les ACLs/Domaines mappes a la volee (c'est pour aller avec le truc au dessus)
Bon ben puisqu'il y a une adresse, je me suis fendu d'un mail.
Désolé c'est en anglais... C'ets un poil agressif, mais c'est lui qui a commencé...
1. "If you're not willing to help fix it then you shouldn't complain about it"
The key motto in successfull open source project is : "release often, release early." Most of the projects I know (open source or not)litterally crave for bug reports. Of course there will be the occasional "send a patch" or "do it yourself" answer. But it is rare. Most of the time developpers actually welcome bugs reports. In fact there are a lot of open sources tools (such as bugzilla) who only job is to facilitate bug reports. Of course if the idea of filling a simple form to have your problems solved is considered to big an effort, and you prefer to sulk on an inapropriate public forum then you will get what you deserved (truly, it is like playing with a kite during a storm).
2. "Open Source software allows you to get under the hood and fix problems"
The keyword here is necessity. If you really need a new function, a correction or a compatiblity feature, you can add it. If you personnally are not gifted enough to do it, then you can pay someone to have it added. Try asking Oracle, Microsoft or Adobe to add whatever function you or your business need. Please send me a copy of their answer if you do, I am sure this could be worth a good laugh.
3. "All software should be free"
Free as bird, Neil, free as a bird. What this phrase meeans is that when you put whatever amount of work, creativity or datas into an application you should be able to get it back and transfer it onto another application without pain.
My job right now is to extract datas from old VMS boxes. I also envoyed coverting photodraw pictures to open standards just so that a friend of mine could get back the equivalent of two months of work (photodraw has been discontinued, and tend to crash severly on XP). As for not paying money for an application or a system, nobody important in the open-source world ever said something like that. In fact even if you get the application for no fee at all, you still have to pay for support, paper documentation, audit etc.
Next time somebody ask you to make a program just explain them that you can develop this either on your own with sources closed or with the open source community. Tell them that the second option will give them full access to the code, the liberty of getting rid of you if you do not satisfy them as a dev (because somebody else will be able to finish/maintain your work) and that they might also get free upgrade and maintenance if the application seduces the community. It might surprise you, but a lot of people are willing to pay a large extra for the second option.
4. "Open Source software is always better than closed, proprietary software"
In terms of quality and fonctionalities there are of course a lot of proprietary software that are better than their open-source equivalent. But they are fewer each day. Furthermore if you need something specific (and 99 times out of 100 you will) in the proprietary context you will very likely have to find exteriors tricks and fixes to have a program fit your needs, making the best program in the world unreliable or very hard to maintain (especially when the guy who made those fixes left the company). Need I talk about the open-source alternative ?
5. "Scratching the personal itch"
This is "Scratching the personal itch" versus "Scratching the general itch". Most software editors are only interressed in almost solving a problem that looks quite like yours. There are of course exceptions, but they are rare. It is the 80/20 law, make a program generic enough to appeal a maximum of customers and don't bloat it with exceptions that only a negligible fraction of people will use. If you need something specific, you will have to pay someone to add it. If your application is proprietary he won't be able to had what you asked in a clean way. On the other hand chances are that among the open-source jungle someone with the exact same problem already developped a solution. Furthermore the KISS (keep it simple, stupid !) ideology often makes it easy to aggregate simple programs inot something that does exactly what you want.
6. "More choice is always better"
If you RTFM ! Need I say more ? I know having to read a book or manual about computers is considered a grave insult today, but you had to read a manuel to set the clock on your VCR, well believe it or not a computer is way more complex than a VCR. Furthermore there are way more programs under windows than under all open-sourced OSes. So sticking to proprietary won't help you on this one...
7. Conclusion: It's Not So Simple
You are right it is not, so stop seeing only what you want to see and give an honest shot at Open-source.
Even though there are flaws in opensource (mainly clashes of ego) it works well enough for IBM to buy. And guess what ? They have been doing computer stuff for even longer than you have.
a) Demoniser fmod pour qu'il ecoute sur un port reseau ou lise dans une zone mémoire partagée
b) faire que les infos de ton appli soient envoyées sur le port ou la zone mémoire en question.
De cette facon fmod et ton appli ne sont pas liés et fmod est facultatif a l'utilisation de ton appli. Par contre tu ne peux toujours pas distribuer ton appli et ton demon fmod dans un même package ou sur un même support.
ouais !! comme ça ils vont etre dégoutés de la GPL, et ils vont utiliser des softs uniquement sous licence BSD...
On s'en moque. Complètement même. Les propriètaires du code ont décidés de mettre a disposition leur travail sous certaines conditions, ne pas respecter ces conditions revient a violer le contrat de license et donc les droits des auteurs du code.
La BSD donne plus de droits que la GPL, mais la GPL a toujours été très claire sur les devoirs qui incombaient aux personnes qui reprennaient le code. Si ces devoirs ne conviennent pas il faut aller voir ailleurs. Personne n'oblige qui que ce soit à inclure du code GPL dans ses produits, à partir de là le choix est laissé aux divers acteurs d'utiliser ou non la GPL.
Il existe aujourd'hui suffisament de licences pour que l'on puisse penser que les auteurs (au sens large) d'un programme ou d'un morceau de code savaient ce qu'ils faisaient quand ils ont choisis une license plutôt qu'une autre. A partir de là c'est vérouillé. Les utilisateurs n'ont pas droit au chapitre quand il s'agit du choix de la license, tout ce qu'ils peuvent faire c'est de faire jouer la concurence.
Bah en C++ je crois que la norme précise que 0 == NULL.
pas tout a fait presque mais pas du tout.
En fait en C++ les pointeurs on une structure forte, et le typage (pourtant pas violent en C++) assure que la valeur 0 va êre encadré comme il faut. A parir de là comme BS n'aime pas du tout les maccros il dit qu'il vaut beaucoup mieux faire p=0 que p=NULL.
En effet dans le cas p=0 le compilo va reperer le pointeur et mettre le 0 dans une structure qui va bien.
Par contre si on a une fonction de type :
f(a) ou a peut être soit un entier soit un pointeur et que l'on apelle f(0) (ou f(5) d'ailleurs) ca sera toujours pris comme étant un entier.
Donc a part pour "affecter" un pointeur l'écriture de 0 en leiu et place de NULL est pas forcément conseillée, mais si on sait ce que l'on fait ca passe très bien.
Cette histoire de prépocesseur qui remplace les 0 par des pointeurs invalides si le 0 n'est pas suffisament invalide m'a l'air complétement tordue!!!
Tu as de la chance. C'est juste que tu n'as jamais bossé sur des archis ou dans des contextes ou l'adresse 0 est interressante. Pour le coté exotique je citerais entre autres:
- Dos et variantes
- Windows avant 1995
- OS2 et variantes
-Mac OS jusqu'à 8 (et un peu 9 aussi mais moins)
- Processeurs zilog (Z80 et consors)
etc.
Cette histoire de prépocesseur qui remplace les 0 par des pointeurs invalides si le 0 n'est pas suffisament invalide m'a l'air complétement tordue!!!
Ben pourtant. Si l'adresse 0 existe et est utile, il faut bien pouvoir y acceder non ? De fait il faut bien que le compilo puisse faire la différence entre un pointeur vers l'adresse 0 valide et un autre qui est invalide. Au final c'est la front-end (on va faire plaisir aux codeurs C) qui s'en occupe.
C'est peut être le cas sur certaines architectures où on veut à tout pris pouvoir exploiter l'adresse 0 au mépris de la portabilité
Au moment ou la base de ces architectures a été créé on vérifiait la comptabilité fortran, éventuellement CP/M. On a gardé ce genre d'architecture après pour la compatibilité avec leurs ancètres.
Il faut cependant remarquer qu'il s'agit alors d'une constante... et c'est effectivement pour ça que le compilateur te laisse accéder à 0 comme tu le veux et que cette convention du « 0 <=> adresse invalide » n'est pas connu du compilateur.
C'est bienle prob, quelqu'un doit la traiter en amont sur les architectures ou 1) l'adresse 0 est valide et 2) on veut la compatibilité avec le C dans le reste du monde. Donc c'est toute l'étape de preprocessing qui s'en occupe.
Rien ne t'empêche cependant de réécrire un malloc() qui renvoie 0xFFFFFFFF si l'allocation ne peut pas se faire pour pouvoir exploiter normalement ton système
Alors là tu vas reveillr un troll qui n'a pas revu le jour depuis des années. Avant le C, les fonction qui retournait des valeurs (Bonc OK les jump sub routine qui remplissait des registres) se comportait comme suit :
regsitre a 0 : tout s'est bien passé
registre a N (N>0) : erreur n°N
registre a -1 : instruction illégale
Quand le C est parti pour l'inverse il y a eu des grincement de dents.
Perso j'utilise toujours la vieille notation pour mes progs a moi, avec un gros entete dans mes fichiers. Bon ca c'est pour les fonctions en général.
Pour malloc en particulier il renvoit un pointeur vers la zone mémoire libérée, lequel est éventuellement NULL.
Et citer malloc ici ne fait pas vraiment avancer le débat : Si mon preprocessing corrige les sorties à 0 des fonctions dont la signature indique qu'ils renvoient un pointeur, il corrigera celle de malloc avant la compil. Donc je ne casserai aucune compatibilité source vu que la correction sera faite par le prepro/front end en aval du source...
mais je t'avouerais que je préfèrerais perdre 1 octet de RAM plutôt que tenter de réinventer un ersatz de langage C avec des conventions différentes.
Aujourd'hui tout le monde fait ca. Mais a l'epoque ou on achetait les 2Mo de ram pour plusieurs milliers de francs et ou on ne pouvait accéder a la mémoire que par pages de 4ko la simple pensée de fiche en l'air 512 octets par barrette ne faisait rire personne.
Pour l'atari ST, il s'agit ici d'émulation donc de compatibilité au niveau binaire. Il est clair que l'on ne peut pas surveiller toutes les allocations et tous les jumps pour vérifier que l'adresse ne vaut pas 0. D'ou le hack.
Pour rappel, le préprocesseur, c'est le truc qui s'occupe des lignes qui commencent par '#' et la substitution des macros. Le front-end, c'est le truc qui parse le source avant la génération de code.
On a déjà un troll sur NULL on va pas aussi rentrer dans celui : "le front-end fait-il partie de l'etape de preprocessing".
Pour ceux qui ne connaissent pas les deux réponses possibles sont :
- Ben oui vu que c'est avant la compil
- Ben non vu que l'init de la compil est une partie de la compil.
Comme il arrive (vive M4, gloire a M4, longue vie a M4, je deteste M4...) qu'on est des echanges front-end <-> préparseur je range le front-end dans le preprocessing.
Mais c'est mon opinion perso et j'ai pas envie de me faire flamer la tête une fois de plus sur ce sujet...
Je suis entièrement d'accord avec toi. Le principal reste cependant que le preproc puisse savoir a quoi il a à faire. Sinon ca part en vrille.
i= (void *)0 // initialisation avec un pointeur (pour faire un reset :-))
La le preprocesseur C t'enverra bouller. Il se dépechera de remplacer ton (void *)0 par une adresse particulière qui permettra au compilo de comprendre qu'il a à faire a un pointeur invalide. Généralement il faut passer par une autre macro.
Au final tu as souvent un truc du genre
{one pass preproc}
(\*.*=) 0 -> %1 = &hFFFFFFFF (tout ce qui est de la forme *toto=0 devient *toto=&hFFFFFFFF ou &hFFFFFFFF est invalide)
NULL -> &hFFFFFFFF
(void\*)0 -> &hFFFFFFFF (tous les (void*)0 sont remplacés comme plus haut )
___reset -> &h00000000
Bref les preprocesseurs essayent de se blinder contre les mecs qui rentrent la valeur 0 dans un pointeur et remplace avant compil tous les zéros rencontrés par une adresse invalide ou un jeu d'instruction pour que le compilo comprenne bien que ca n'est plus un pointeur.
En bref si p est un pointeur
p=0 sera remplacé de facon triviale par le préprocesseur et le pointeur p sera invalide.
Derrière il sera impossible de faire un p++.
De même si tu lis la norme posix, on a souvent :
- return NULL if ....
Mais pas
- return 0 if ...
Normalement avec la signature de la fonction on doit pouvoir s'en sortir. Si c'est un pointeur en retour alors 0=NULL, sinon c'est bien un 0 tout ce qu'il y a de plus standard.
Bien sur si la fonction est bizaroide au point que l'on sait qu'elle retourne quelquechose mais que l'on ne sait pas si c'est un pointeur ou pas la on a un problème et le NULL est obligatoire. Mais il est théoriquement impssible de faire uen telle fonction.
Dans les bonnes règles de programmation on rappèle toujours qu'il ne faut pas considérer qu'un pointeur est un entier.
Faire ne serait-ce qu'une semaine d'assembleur permet de connaitre la différence pour toute la vie. Même si la mémoire est continue...
Peut-être qu'un jour les compilateurs mettrons un gros warning lorsqu'un pointeur est initialisé avec un int.
ben si tu fais
int i=2;
char *a=i;
On peut remonter un warning (et c'est déjà le cas).
Par contre si tu fais char *a=2 .... C'est valide et il faut que ca le reste, 2 est une adresse mémoire tout ce qu'il y a de plus valable.
Ceci étant je suis également partisan du NULL en lieu et place du 0, mais c'est principalement pour la lisibilité. Quelqu'un qui veut utiliser des 0 a la place peut le faire si il est propre dans son code.
AAARRRRGGGGHHHH !!!!
Et dire que j'avais pensé sortir de ce troll collant depuis que je ne fréquantais plus les newsgroup de prog.
Pour faire simple et rapide :
Il existe un tas d'architecture pour laquelle l'adresse 0 est tout a fait valable. Et parmis ces architecture on trouve notre bonne vieille x86. De facon assez simple :
- Toutes les machines capables de gérer nativement la mémoire en mode segment ou en mode page ont besoin de l'adresse 0 (violament même).
- Pas mal de machines utilisent l'adresse 0 comme reset (Zilog et certains PICS si je me souviens bien + truc plus exotique a coté).
- Dans le cas ou l'adresse 0 est un pointeur vers une fonction hardcodé (reset, init, firmware load etc..) alors
a) cette fonction devrait être de type void (on voit mal a quoi une fonction d'init pourrait renvoyer des infos)
b) elle pointe vers 0
Sur toutes ces architectures, normalement aussi bien (void *)0 que 0 sont des pointeurs on ne peut plus valide.
Donc difficile de faire
#define NULL (void *)0
ou
#define NULL 0
Si sizeof(int) != sizeof(void *) (typiquement le cas sur machine 64 bits), des problèmes sont à prévoir.
Le problème c'est que de par le type (bon le non type) de void * on peut avoir sur certaines architectures :
sizeof(void *) != sizeof(void *), ceux qui ont déjà joué un peu avec des jump far et des jump near en assembleur x86 (ou autre) voient de quoi je parle.
La taille des pointeurs (et ce jusqu'au niveau des registres qui les stoquent) peut varier en fonction du contexte CPU. Et là c'est la fête au village quelque soit la définition de int ou de void ou même de long...
Bon maintenant, on en est au moment ou on se rend compte que si on veut un truc qui marche sur toutes les archis, on ne peut pas définir NULL dans le code.
A partir de là , il est assez facile de déduire que c'est le boulot du preprocesseur/precompileur de faire le tri la dedans.
Par exemple si l'adresse 0 est valide c'est a lui de repérer les appels de type *p = NULL ou *p = 0 et de les remplacer par l'adresse non valide de son choix. Dans le cas de contextes ou les types ne font pas la même longueur c'est au dev de permettre au préprocesseur de faire la différence :
- soit en créant des signatures de fonctions qui ne laissent pas la place au doute
genre si toto(int i, typea j, typeb k) existe éviter de faire une autre fonction toto(void* i, typea j, typeb k), mais faire : toto(typea j, typeb k, void* j)
Ou alors s'arranger pour que le type soit forcément défini quand il arrive dans la fonction, genre test if i!=0 then toto(i,j,k).
Grosso modo l'erreur de prog ne vient pas quand on fait *p=0 mais quand on balade des pointeurs dont on ne connait pas le type et dont on ne sait pas si ils sont nuls ou pas dans un contexte tel que le préprocesseur ne peut pas faire la différence.
A noter que les chances de se planter sont souvent infimes avec NULL et plutôt élevée avec 0, sauf si vous vous amusez a redéfinir NULL. Auquel cas a vous de vous débrouiller avec votre préprocesseur pour ne pas qu'il s'enmèle les pinceaux.
Un bon petit FreeBSD, voire un NetBSD, ca te conviendrait peut-être, mais je ne suis pas catégorique sur la durée de support.
Je suis entièrement d'accord avec toi, bien que le noyeau 2.6 ai fait de gros progrès à ce niveau, FreeBSD reste l'OS des serveurs polyvalent. Personellement c'est quasiment toujours vers une solution FreeBSD 4.x quand j'i un serveur a monter.
Bien sûr, le "problème", c'est que tu n'as pas apt-get, et il faudra donc que tu t'habitues à un autre système.
S'habituer a package qand on a connu apt ca va très vite. Les ystèmes sont pour ainsi dire identiques, au moins dans l'esprit si ce n'est dans les faits. A part un jeu de correspondances entre les commandes il n'y a pas grand chose a apprendre.
Par contre l'init BSD peut dérouter un peu au début, mais une fois de plus le système Debian est très proche de FreeBSD. L'adaptation se fait assez facilement.
Les brevets apparaissent lorsque l'inovation ralentit : quand un nouveau domaine apparait, le bouillonement d'idées fait que les idées d'aujourd'hui seront obsolètes demain.
C'est bien là le problème. ca c'ets ce qui devrait se passer, a savoir quand trouver de nouvelles idées devient difficile, alors ceux qui continuent a chercher sont récompensés de leurs efforts. En pratique lors du tout début d'une techno, une boite qui a les moyens financiers de déposer des brevets dans tous les sens finira forcément par déposer un brevet sur du fondamental. Car toutes les idées d'aujourd'hui ne deviennent pas obsolète le lendemain, loin de là, certaines servent de bases aux constructions futures. Même en informatique, qui a mon sens en est encore a la phase "bouillonement", bien que l'on réinvente la roue en permanence, certains éléments servent de base a des cosntructions plus ambitieuses. Les SGBD, les langages objets, les systèmes de traitement du signal par ondelettes, les URI et URL, la navigaution spatiale ou par arbre dans un système de fichier etc.
C'est dans ce cas là que le brevet est le plsu nuisible : breveter tout et n'importe quoi parcequ'on a les moyens financiers de le faire et ensuite viser les grosses boite avec des brevets sur des technologies qui sont depuis devenues fondamentales.
Pour ceux qui n'aiment pas les jeux de pistes un bref résumé :
- On a commencé a se poser la question du déploiement et de la mise a jour a distance en 1983. En 1987 IBM faisait une recherche sur l'ensemble des méthodes utilisables pour faire du controle de mise a jour d'applications logicielles. Compuserve mettait déjà a disposition de ses clients un système de mise a jour automatiques des paramètres de config en 1988 et en 1989 un chercheur de l'université de Carnegie Mellon jetais les bases d'un protocole de mise a jour de logiciels (qui n'a manifestement pas eu trop de succès).
Ensuite c'est BSD qui rentre dans la danse :
Les networking release de BSD 4.3 (Network1 : 1990, reno : 1990 et Network2 : juin 1991) possédaient déjà un système d'installation et de mise a jour par internet (mais non automatisés). En 1991 386/BSD est diponible exclusivement via FTP. NetBSD le premier "fork" restera sur internet exclusivement jusqu'en 1998.
Les systeme de Package utilisé actuellement date de 1994, juste après le procès USL vs BSDI and Univeristy of California (Qui ressemble a s'y méprendre au procès que SCO essaye de faire a Linux). Mais il y a eu des embryons spécialisés dès 1992 (Que l'on trouve dans les premières versions de NetBSD).
Donc la recherche sur le sujet existe depuis 1983, mais les systèmes vraiment automatisés ne se sont présentés que vers 1992-1993. Entre temps entre 1988 et 1992 il y a eu un certain nombre de systèmes qui pertmettaient des mises a jour manuelles simple avec résolution automatique des diverses dépendances.
Donc sur ce coup là c'est un peu tendu. Le brevet n'est pas trivialement absurde. Si BTG a vraiment mis au point son sytème dans les années 90-91-92 trouver un antécédent avec des fonctions similaires risque de demander un peu de recherche.
Si il y a des survivant du crétacé inférieur qui peuvent nous confirmer l'existence de systèmes de mise a jour/deploiement a distance avant 1990, merci de se faire connaitre.
Pas encore complètement. Par contre ils auront interêt a se dépécher de reserver leur domaine le jour ou ce sera possible car il y a fort a parier que la gentille boite qui propose de s'y prendre a l'avance va décider de déposer les noms de domaine pour elle-même. Juste histoire de pouvoir squatter un peu et de faire monter les enchères...
[^] # Re: Performances ?
Posté par Jerome Herman . En réponse à la dépêche XCB : bientôt la version 1. Évalué à 6.
Pas vraiment, l'idée générale est que cela devrait être globalement très bénéfique.
Je m'explique, si il y a une seule application sur le serveur X, alors le lock exclusif n'est pas vraiment génant, si elle est non threadée alors le lock est même plutot bénéfique en termes de perfs (pas besoin de mutexs, de vérifier les conditions de course etc.). Par contre dans a peu près tous les autres cas XCB devrait permettre au serveur X de s'occupper de plusieurs applications en même temps, pas besoin par exemple d'attendre d'avoir renvoyé l'intégralité d'un bitmap a une fenetre (fausse transparence entre autre) pour pouvoir afficher du texte dans une autre.
Kha
[^] # Re: Cette hiérarchie à trois niveaux suffit
Posté par Jerome Herman . En réponse au journal Article sur les ACLs sur LinuxFrench. Évalué à 2.
On rencontre la vrai limite des droits Unix dans le cas suivant :
On veut un groupe en execution seule sur un repertoire (les utilisateurs) et un groupe en lecture/ecriture/execution (les admins du programe). Ben là ca devient complexe. Bonjour la floraison de SetUID et de SetGID....
Si dérrière il faut un groupe en lecture/execution (pour l'audit) et un groupe en lecture seule (pour les back-ups) c'est carrément la fête au village.
Kha
[^] # Re: Ben voyons fit le hanneton
Posté par Jerome Herman . En réponse à la dépêche Trop de licences libres ?. Évalué à 2.
Et la GPL ? Tu crois que le fait de pouvoir récupérer toutes les modifs faites a ton source sur tous les programmes distribués qui l'utilisent comme base ca n'est pas un droit ?
Le fait que tu restes dans la liste des auteurs, que tu puisses te défendre contre des gens qui ne respectent la GPL attenante a ton code etc. C'est des droits !
Une license sert a donner des droits et a en garder. Et en GPL on garde pas mal de droit et on impose pas mal de devoir aux contributeurs...
Kha
[^] # Re: Ben voyons fit le hanneton
Posté par Jerome Herman . En réponse à la dépêche Trop de licences libres ?. Évalué à 5.
L'interet principal d'une licence est de protéger ses droits. L'auteur choisit la licence qui lui convient le mieux et y apporte éventuellement des modifications/corrections pour avoir exactement ce qu'il veut.
L'échange de code entre les projets, même si il est philosophiquement la pierre d'angle du libre, n'est vis a vis de la license qu'une des conditions d'utilisation. Un auteur qui n'utilise pas telle ou telle licence peut tomber dans deux cas différents :
- a) il s'en fout ou il n'a jamais entendu parler de la licence en question, dans ce cas là avec un simple echange d'emails on arrive souvent a obtenir le code sous une licence qui convient mieux. A partir de là on n'a pas a réinventer la roue.
- b) Pour des raisons qui le regarde il ne veut pas de la license qui vous arrangerait vous. Dans ce cas là, comme c'est lui l'auteur du code, c'est lui qui décide. Mais a moins de tomber sur une grosse boite qui joue a faire du libre pour pouvoir apater le badaud, il sera très sans doute prêt a vous aider a construire une alternative a son code et a vous fournir moults conseils et corrections (sauf le projet XFree bien sur, mais c'est un peu l'exception qui confirme la règle.)
Tiens d'ailleurs : chiche d'envoyer un email a RMS en disant que l'on est en train de faire un emacs like en C++ sous licence BSD et d elui demander son point de vue là dessus ? Ca pourrait être drole.
Kha
P.S Hors sujet : en ce qui concerne le droit d'écrire, il faut savoir que passer un texte en licence libre de façon porpre en France est une opération relativement complexe, qui implique entre autre de déposer ses droits avant de renoncer a une partie d'entre eux (compliqué encore par le fait que comme le texte est paru en avant première sur DLFP, il me faudrait un papier des responsables du site disant qu'ils ne sont pas mes éditeurs et que le texte m'appartient pleinement.). Je ne me sens pas de faire çà la maintenant, tout de suite. Mais patience, a défaut de licence libre il y aura peut-être une surprise.
# Ben voyons fit le hanneton
Posté par Jerome Herman . En réponse à la dépêche Trop de licences libres ?. Évalué à 10.
Sur un système propriétaire (au hasard windows) rien que les outils basiques sont souvent soumis a bien plus que 52 licences.
Faut pas révé, entre la license originale, celle de la mise a jour, celles des patchs, celle du lecteur audio-vidéo, celle du logiciel de messagerie, celle du navigateur, celle du logiciel de messagerie instantanée etc. Un client ou prospect sera supposé avoir lu, compris et accepté bien plus de 52 licences subtilement différentes entre le moment ou il insère le CD d'installation dans sa machine et le moment ou il aura fini l'ensemble des mises a jour.
Il ne lui restera ensuite qu'à enchainer sur l'installation de MS Office et du pack internet fourni avec son abonnement. Avant de finir par les outils dont il a besoin professionellement et qui, si ils sont propriétaires, ne manqueront pas d'avoir leur propre license sur une ou plusieurs pages.
Qu'on se le dise 52 licences c'est très peu vu l'ensemble des produits qu'elles recouvrent.
Kha.
[^] # Re: Sympa
Posté par Jerome Herman . En réponse au journal Le droit d'écrire. Évalué à 10.
Oui tout a fait.
même si c'est quand même un peu simpliste
C'est même volontairement un peu caricatural. Mais d'un autre coté c'est supposé avoir lieu dans au moins 100 ans. Et puis comme je voulais un texte assez court, pas assez de talent pour faire une oeuvre majeure. Il y a un certain nombre de raccourcis et d'incohérences dans ce texte. (Mais je ne les dirais pas, a vous de trouver.)
Kha
[^] # Re: pour repondre...
Posté par Jerome Herman . En réponse au journal Cartes ethernet et linux. Évalué à 2.
Il existe un grand nombre de cartes 8139. Le mieux étant de les essayer les unes dérrière les autres.
Les modules différents peuvent être :
n2K-PCI pour les 8139 tout court et certains board A/B
8139CP pour les 8139c est certaines exotiques
8139too pour les cartes un peu plus récentes.
8139too ou b44 pour les realtek respinés par broadcom (avec les b44 si vous vous retrouvez bloqué a 1Ghz alors c'est qui vous faut les bcm440 dispo en GPL sur le site de broadcom.)
Les 8139 sont très répendue, mais les versions un peu plus moderne sont parfois problématiques.
Personellement dès que je peux je mets 30Euros de plus et je prend de l'Intel. Mais ca n'engage que moi.
Kha
[^] # Re: Spoofing et FUD
Posté par Jerome Herman . En réponse à la dépêche Nouvelles failles de sécurité de Mozilla et Firefox. Évalué à 5.
Ca se contourne relativement facilement. Soit en bootant en mode sans echec, soit en le remplacant pendant la boot phase de windows. Personellement le nombre de truc qui se restaurent automatiquement que j'ai giclé de mes Windows XP (Messenger, Outlook, MediaPlayer pour ne citer que les plus célèbres).
Par contre l'autorestore est une fonctionnalité géniale pour les auteurs de virus... Certains spywares s'en servaient avant le SP1, je ne sais pas si c'est encore valable.
Kha
[^] # Re: Remarque sur la sécurité
Posté par Jerome Herman . En réponse au journal PCs Carrefour avec Mandrakelinux préinstallé !!. Évalué à 3.
Oh que si il est utilisable. Malheureusement, parceque 99 fois sur 100 son mot de passe est initialisé a vide.
Pour récuperer les droits sur votre compte admin, pressez F8 pendant le boot de Windows XP, la mire vous présentera alors l'administrateur parmis les options possibles. Vous pourrez alors vérifier que son mot de passe est bien vide et luid onner le mot de passe de votre choix. Sinon vous pouvez le changer depuis n'importe quel compte avec les droits admin sur la machine. Pendant que vous y êtes pensez a le renommer aussi.
Si vous désirez l'utiliser en session normale (donc hors mode sans echec) il vous faudra desactiver la page d'acceuil login et revenir a la boite de dialogue "old school".
Il est bien entendu déconseillé d'utiliser ce compte là pour travailler sur son ordinateur.
Kha
[^] # Re: Sivit ?
Posté par Jerome Herman . En réponse au journal Location d'un serveur dédié.. (mort à OVH). Évalué à 8.
Non il se route sur un segment de reseau très lent pour cripple, et là il se fait dropper.
Ca marche assez bien, mais ca implique d'avoir des routeurs costauds en direct backbone, ce qui est encore un peu cher en France...
Kha
# Marrant, j'ai un choix multiple :
Posté par Jerome Herman . En réponse au sondage Je réinstalle Linux sur mon ordinateur. Évalué à 2.
[x] Souvent, parceque j'ai une partition qui me sert a tester toutes les distribs qui me passent sous la main (et a faire des bugs reports)
[x] Souvent, parceque je teste aussi des emulateurs (Bochs et PearPC, pour ne pas les nommer)
[x] Souvent parceque j'essaye de creer ma propre distrib (En plus c'est du SE_Linux sur crypto loop, une erreur -> poubelle)
[x] Souvent parceque j'essaye de creer une lib de memoire partagee, avec les ACLs/Domaines mappes a la volee (c'est pour aller avec le truc au dessus)
Est-ce grave ?
Kha...
# Et hop un mail
Posté par Jerome Herman . En réponse au journal "Open Source Myths". Évalué à 10.
Désolé c'est en anglais... C'ets un poil agressif, mais c'est lui qui a commencé...
1. "If you're not willing to help fix it then you shouldn't complain about it"
The key motto in successfull open source project is : "release often, release early." Most of the projects I know (open source or not)litterally crave for bug reports. Of course there will be the occasional "send a patch" or "do it yourself" answer. But it is rare. Most of the time developpers actually welcome bugs reports. In fact there are a lot of open sources tools (such as bugzilla) who only job is to facilitate bug reports. Of course if the idea of filling a simple form to have your problems solved is considered to big an effort, and you prefer to sulk on an inapropriate public forum then you will get what you deserved (truly, it is like playing with a kite during a storm).
2. "Open Source software allows you to get under the hood and fix problems"
The keyword here is necessity. If you really need a new function, a correction or a compatiblity feature, you can add it. If you personnally are not gifted enough to do it, then you can pay someone to have it added. Try asking Oracle, Microsoft or Adobe to add whatever function you or your business need. Please send me a copy of their answer if you do, I am sure this could be worth a good laugh.
3. "All software should be free"
Free as bird, Neil, free as a bird. What this phrase meeans is that when you put whatever amount of work, creativity or datas into an application you should be able to get it back and transfer it onto another application without pain.
My job right now is to extract datas from old VMS boxes. I also envoyed coverting photodraw pictures to open standards just so that a friend of mine could get back the equivalent of two months of work (photodraw has been discontinued, and tend to crash severly on XP). As for not paying money for an application or a system, nobody important in the open-source world ever said something like that. In fact even if you get the application for no fee at all, you still have to pay for support, paper documentation, audit etc.
Next time somebody ask you to make a program just explain them that you can develop this either on your own with sources closed or with the open source community. Tell them that the second option will give them full access to the code, the liberty of getting rid of you if you do not satisfy them as a dev (because somebody else will be able to finish/maintain your work) and that they might also get free upgrade and maintenance if the application seduces the community. It might surprise you, but a lot of people are willing to pay a large extra for the second option.
4. "Open Source software is always better than closed, proprietary software"
In terms of quality and fonctionalities there are of course a lot of proprietary software that are better than their open-source equivalent. But they are fewer each day. Furthermore if you need something specific (and 99 times out of 100 you will) in the proprietary context you will very likely have to find exteriors tricks and fixes to have a program fit your needs, making the best program in the world unreliable or very hard to maintain (especially when the guy who made those fixes left the company). Need I talk about the open-source alternative ?
5. "Scratching the personal itch"
This is "Scratching the personal itch" versus "Scratching the general itch". Most software editors are only interressed in almost solving a problem that looks quite like yours. There are of course exceptions, but they are rare. It is the 80/20 law, make a program generic enough to appeal a maximum of customers and don't bloat it with exceptions that only a negligible fraction of people will use. If you need something specific, you will have to pay someone to add it. If your application is proprietary he won't be able to had what you asked in a clean way. On the other hand chances are that among the open-source jungle someone with the exact same problem already developped a solution. Furthermore the KISS (keep it simple, stupid !) ideology often makes it easy to aggregate simple programs inot something that does exactly what you want.
6. "More choice is always better"
If you RTFM ! Need I say more ? I know having to read a book or manual about computers is considered a grave insult today, but you had to read a manuel to set the clock on your VCR, well believe it or not a computer is way more complex than a VCR. Furthermore there are way more programs under windows than under all open-sourced OSes. So sticking to proprietary won't help you on this one...
7. Conclusion: It's Not So Simple
You are right it is not, so stop seeing only what you want to see and give an honest shot at Open-source.
Even though there are flaws in opensource (mainly clashes of ego) it works well enough for IBM to buy. And guess what ? They have been doing computer stuff for even longer than you have.
Kha
# Pas gagné
Posté par Jerome Herman . En réponse au journal fmod, licence, GPL toussa. Évalué à 3.
a) Demoniser fmod pour qu'il ecoute sur un port reseau ou lise dans une zone mémoire partagée
b) faire que les infos de ton appli soient envoyées sur le port ou la zone mémoire en question.
De cette facon fmod et ton appli ne sont pas liés et fmod est facultatif a l'utilisation de ton appli. Par contre tu ne peux toujours pas distribuer ton appli et ton demon fmod dans un même package ou sur un même support.
Question pourquoi ne pas plutot essayer de reprendre un des nombreux plugins mod qui existent dans xmms pour les transformer a ta sauce ?
il y a le modplug qui est très versatile http://modplug-xmms.sourceforge.net/(...)
le mikmod qui est pas très fidèle mais simple :
http://mikmod.raphnet.net/(...)
et xmp qui existe déjà sur pas mal de plateformes
http://xmp.sourceforge.net/(...)
Et surement d'autres.
Kha
[^] # Re: OUAIIIIIS
Posté par Jerome Herman . En réponse à la dépêche La justice allemande déclare la GNU GPL valide. Évalué à 10.
On s'en moque. Complètement même. Les propriètaires du code ont décidés de mettre a disposition leur travail sous certaines conditions, ne pas respecter ces conditions revient a violer le contrat de license et donc les droits des auteurs du code.
La BSD donne plus de droits que la GPL, mais la GPL a toujours été très claire sur les devoirs qui incombaient aux personnes qui reprennaient le code. Si ces devoirs ne conviennent pas il faut aller voir ailleurs. Personne n'oblige qui que ce soit à inclure du code GPL dans ses produits, à partir de là le choix est laissé aux divers acteurs d'utiliser ou non la GPL.
Il existe aujourd'hui suffisament de licences pour que l'on puisse penser que les auteurs (au sens large) d'un programme ou d'un morceau de code savaient ce qu'ils faisaient quand ils ont choisis une license plutôt qu'une autre. A partir de là c'est vérouillé. Les utilisateurs n'ont pas droit au chapitre quand il s'agit du choix de la license, tout ce qu'ils peuvent faire c'est de faire jouer la concurence.
Kha
[^] # Re: Trop violent
Posté par Jerome Herman . En réponse au journal J'adore Linus. Évalué à 2.
pas tout a fait presque mais pas du tout.
En fait en C++ les pointeurs on une structure forte, et le typage (pourtant pas violent en C++) assure que la valeur 0 va êre encadré comme il faut. A parir de là comme BS n'aime pas du tout les maccros il dit qu'il vaut beaucoup mieux faire p=0 que p=NULL.
En effet dans le cas p=0 le compilo va reperer le pointeur et mettre le 0 dans une structure qui va bien.
Par contre si on a une fonction de type :
f(a) ou a peut être soit un entier soit un pointeur et que l'on apelle f(0) (ou f(5) d'ailleurs) ca sera toujours pris comme étant un entier.
Donc a part pour "affecter" un pointeur l'écriture de 0 en leiu et place de NULL est pas forcément conseillée, mais si on sait ce que l'on fait ca passe très bien.
Kha
[^] # Re: Petites precisions
Posté par Jerome Herman . En réponse au journal J'adore Linus. Évalué à 2.
Tu as de la chance. C'est juste que tu n'as jamais bossé sur des archis ou dans des contextes ou l'adresse 0 est interressante. Pour le coté exotique je citerais entre autres:
- Dos et variantes
- Windows avant 1995
- OS2 et variantes
-Mac OS jusqu'à 8 (et un peu 9 aussi mais moins)
- Processeurs zilog (Z80 et consors)
etc.
Cette histoire de prépocesseur qui remplace les 0 par des pointeurs invalides si le 0 n'est pas suffisament invalide m'a l'air complétement tordue!!!
Ben pourtant. Si l'adresse 0 existe et est utile, il faut bien pouvoir y acceder non ? De fait il faut bien que le compilo puisse faire la différence entre un pointeur vers l'adresse 0 valide et un autre qui est invalide. Au final c'est la front-end (on va faire plaisir aux codeurs C) qui s'en occupe.
C'est peut être le cas sur certaines architectures où on veut à tout pris pouvoir exploiter l'adresse 0 au mépris de la portabilité
Au moment ou la base de ces architectures a été créé on vérifiait la comptabilité fortran, éventuellement CP/M. On a gardé ce genre d'architecture après pour la compatibilité avec leurs ancètres.
Il faut cependant remarquer qu'il s'agit alors d'une constante... et c'est effectivement pour ça que le compilateur te laisse accéder à 0 comme tu le veux et que cette convention du « 0 <=> adresse invalide » n'est pas connu du compilateur.
C'est bienle prob, quelqu'un doit la traiter en amont sur les architectures ou 1) l'adresse 0 est valide et 2) on veut la compatibilité avec le C dans le reste du monde. Donc c'est toute l'étape de preprocessing qui s'en occupe.
Rien ne t'empêche cependant de réécrire un malloc() qui renvoie 0xFFFFFFFF si l'allocation ne peut pas se faire pour pouvoir exploiter normalement ton système
Alors là tu vas reveillr un troll qui n'a pas revu le jour depuis des années. Avant le C, les fonction qui retournait des valeurs (Bonc OK les jump sub routine qui remplissait des registres) se comportait comme suit :
regsitre a 0 : tout s'est bien passé
registre a N (N>0) : erreur n°N
registre a -1 : instruction illégale
Quand le C est parti pour l'inverse il y a eu des grincement de dents.
Perso j'utilise toujours la vieille notation pour mes progs a moi, avec un gros entete dans mes fichiers. Bon ca c'est pour les fonctions en général.
Pour malloc en particulier il renvoit un pointeur vers la zone mémoire libérée, lequel est éventuellement NULL.
Et citer malloc ici ne fait pas vraiment avancer le débat : Si mon preprocessing corrige les sorties à 0 des fonctions dont la signature indique qu'ils renvoient un pointeur, il corrigera celle de malloc avant la compil. Donc je ne casserai aucune compatibilité source vu que la correction sera faite par le prepro/front end en aval du source...
mais je t'avouerais que je préfèrerais perdre 1 octet de RAM plutôt que tenter de réinventer un ersatz de langage C avec des conventions différentes.
Aujourd'hui tout le monde fait ca. Mais a l'epoque ou on achetait les 2Mo de ram pour plusieurs milliers de francs et ou on ne pouvait accéder a la mémoire que par pages de 4ko la simple pensée de fiche en l'air 512 octets par barrette ne faisait rire personne.
Pour l'atari ST, il s'agit ici d'émulation donc de compatibilité au niveau binaire. Il est clair que l'on ne peut pas surveiller toutes les allocations et tous les jumps pour vérifier que l'adresse ne vaut pas 0. D'ou le hack.
Kha
Qui se sent vieux, mais vieux...
[^] # Re: Petites precisions
Posté par Jerome Herman . En réponse au journal J'adore Linus. Évalué à 3.
On a déjà un troll sur NULL on va pas aussi rentrer dans celui : "le front-end fait-il partie de l'etape de preprocessing".
Pour ceux qui ne connaissent pas les deux réponses possibles sont :
- Ben oui vu que c'est avant la compil
- Ben non vu que l'init de la compil est une partie de la compil.
Comme il arrive (vive M4, gloire a M4, longue vie a M4, je deteste M4...) qu'on est des echanges front-end <-> préparseur je range le front-end dans le preprocessing.
Mais c'est mon opinion perso et j'ai pas envie de me faire flamer la tête une fois de plus sur ce sujet...
Kha
[^] # Re: Petites precisions
Posté par Jerome Herman . En réponse au journal J'adore Linus. Évalué à 5.
i= (void *)0 // initialisation avec un pointeur (pour faire un reset :-))
La le preprocesseur C t'enverra bouller. Il se dépechera de remplacer ton (void *)0 par une adresse particulière qui permettra au compilo de comprendre qu'il a à faire a un pointeur invalide. Généralement il faut passer par une autre macro.
Au final tu as souvent un truc du genre
{one pass preproc}
(\*.*=) 0 -> %1 = &hFFFFFFFF (tout ce qui est de la forme *toto=0 devient *toto=&hFFFFFFFF ou &hFFFFFFFF est invalide)
NULL -> &hFFFFFFFF
(void\*)0 -> &hFFFFFFFF (tous les (void*)0 sont remplacés comme plus haut )
___reset -> &h00000000
Bref les preprocesseurs essayent de se blinder contre les mecs qui rentrent la valeur 0 dans un pointeur et remplace avant compil tous les zéros rencontrés par une adresse invalide ou un jeu d'instruction pour que le compilo comprenne bien que ca n'est plus un pointeur.
En bref si p est un pointeur
p=0 sera remplacé de facon triviale par le préprocesseur et le pointeur p sera invalide.
Derrière il sera impossible de faire un p++.
De même si tu lis la norme posix, on a souvent :
- return NULL if ....
Mais pas
- return 0 if ...
Normalement avec la signature de la fonction on doit pouvoir s'en sortir. Si c'est un pointeur en retour alors 0=NULL, sinon c'est bien un 0 tout ce qu'il y a de plus standard.
Bien sur si la fonction est bizaroide au point que l'on sait qu'elle retourne quelquechose mais que l'on ne sait pas si c'est un pointeur ou pas la on a un problème et le NULL est obligatoire. Mais il est théoriquement impssible de faire uen telle fonction.
Dans les bonnes règles de programmation on rappèle toujours qu'il ne faut pas considérer qu'un pointeur est un entier.
Faire ne serait-ce qu'une semaine d'assembleur permet de connaitre la différence pour toute la vie. Même si la mémoire est continue...
Peut-être qu'un jour les compilateurs mettrons un gros warning lorsqu'un pointeur est initialisé avec un int.
ben si tu fais
int i=2;
char *a=i;
On peut remonter un warning (et c'est déjà le cas).
Par contre si tu fais char *a=2 .... C'est valide et il faut que ca le reste, 2 est une adresse mémoire tout ce qu'il y a de plus valable.
Ceci étant je suis également partisan du NULL en lieu et place du 0, mais c'est principalement pour la lisibilité. Quelqu'un qui veut utiliser des 0 a la place peut le faire si il est propre dans son code.
Kha
[^] # Re: C != C++
Posté par Jerome Herman . En réponse au journal J'adore Linus. Évalué à 4.
Bof ils ont l'habitude maintenant...
Ca revient periodiquement.
Kha
[^] # Re: Petites precisions
Posté par Jerome Herman . En réponse au journal J'adore Linus. Évalué à 10.
Et dire que j'avais pensé sortir de ce troll collant depuis que je ne fréquantais plus les newsgroup de prog.
Pour faire simple et rapide :
Il existe un tas d'architecture pour laquelle l'adresse 0 est tout a fait valable. Et parmis ces architecture on trouve notre bonne vieille x86. De facon assez simple :
- Toutes les machines capables de gérer nativement la mémoire en mode segment ou en mode page ont besoin de l'adresse 0 (violament même).
- Pas mal de machines utilisent l'adresse 0 comme reset (Zilog et certains PICS si je me souviens bien + truc plus exotique a coté).
- Dans le cas ou l'adresse 0 est un pointeur vers une fonction hardcodé (reset, init, firmware load etc..) alors
a) cette fonction devrait être de type void (on voit mal a quoi une fonction d'init pourrait renvoyer des infos)
b) elle pointe vers 0
Sur toutes ces architectures, normalement aussi bien (void *)0 que 0 sont des pointeurs on ne peut plus valide.
Donc difficile de faire
#define NULL (void *)0
ou
#define NULL 0
Si sizeof(int) != sizeof(void *) (typiquement le cas sur machine 64 bits), des problèmes sont à prévoir.
Le problème c'est que de par le type (bon le non type) de void * on peut avoir sur certaines architectures :
sizeof(void *) != sizeof(void *), ceux qui ont déjà joué un peu avec des jump far et des jump near en assembleur x86 (ou autre) voient de quoi je parle.
La taille des pointeurs (et ce jusqu'au niveau des registres qui les stoquent) peut varier en fonction du contexte CPU. Et là c'est la fête au village quelque soit la définition de int ou de void ou même de long...
Bon maintenant, on en est au moment ou on se rend compte que si on veut un truc qui marche sur toutes les archis, on ne peut pas définir NULL dans le code.
A partir de là , il est assez facile de déduire que c'est le boulot du preprocesseur/precompileur de faire le tri la dedans.
Par exemple si l'adresse 0 est valide c'est a lui de repérer les appels de type *p = NULL ou *p = 0 et de les remplacer par l'adresse non valide de son choix. Dans le cas de contextes ou les types ne font pas la même longueur c'est au dev de permettre au préprocesseur de faire la différence :
- soit en créant des signatures de fonctions qui ne laissent pas la place au doute
genre si toto(int i, typea j, typeb k) existe éviter de faire une autre fonction toto(void* i, typea j, typeb k), mais faire : toto(typea j, typeb k, void* j)
Ou alors s'arranger pour que le type soit forcément défini quand il arrive dans la fonction, genre test if i!=0 then toto(i,j,k).
Grosso modo l'erreur de prog ne vient pas quand on fait *p=0 mais quand on balade des pointeurs dont on ne connait pas le type et dont on ne sait pas si ils sont nuls ou pas dans un contexte tel que le préprocesseur ne peut pas faire la différence.
A noter que les chances de se planter sont souvent infimes avec NULL et plutôt élevée avec 0, sauf si vous vous amusez a redéfinir NULL. Auquel cas a vous de vous débrouiller avec votre préprocesseur pour ne pas qu'il s'enmèle les pinceaux.
Kha
[^] # Re: rediff ?
Posté par Jerome Herman . En réponse au journal Reportage Arte sur l'industrie du disque.. Évalué à 5.
Kha
[^] # Re: Une connerie de ma part probablement
Posté par Jerome Herman . En réponse au journal Sarge décision. Évalué à 2.
Je suis entièrement d'accord avec toi, bien que le noyeau 2.6 ai fait de gros progrès à ce niveau, FreeBSD reste l'OS des serveurs polyvalent. Personellement c'est quasiment toujours vers une solution FreeBSD 4.x quand j'i un serveur a monter.
Bien sûr, le "problème", c'est que tu n'as pas apt-get, et il faudra donc que tu t'habitues à un autre système.
S'habituer a package qand on a connu apt ca va très vite. Les ystèmes sont pour ainsi dire identiques, au moins dans l'esprit si ce n'est dans les faits. A part un jeu de correspondances entre les commandes il n'y a pas grand chose a apprendre.
Par contre l'init BSD peut dérouter un peu au début, mais une fois de plus le système Debian est très proche de FreeBSD. L'adaptation se fait assez facilement.
Kha
[^] # Re: les brevets peuvent ils favoriser l'innovation ?
Posté par Jerome Herman . En réponse à la dépêche Microsoft et Apple poursuivis pour violation de brevet. Évalué à 10.
C'est bien là le problème. ca c'ets ce qui devrait se passer, a savoir quand trouver de nouvelles idées devient difficile, alors ceux qui continuent a chercher sont récompensés de leurs efforts. En pratique lors du tout début d'une techno, une boite qui a les moyens financiers de déposer des brevets dans tous les sens finira forcément par déposer un brevet sur du fondamental. Car toutes les idées d'aujourd'hui ne deviennent pas obsolète le lendemain, loin de là, certaines servent de bases aux constructions futures. Même en informatique, qui a mon sens en est encore a la phase "bouillonement", bien que l'on réinvente la roue en permanence, certains éléments servent de base a des cosntructions plus ambitieuses. Les SGBD, les langages objets, les systèmes de traitement du signal par ondelettes, les URI et URL, la navigaution spatiale ou par arbre dans un système de fichier etc.
C'est dans ce cas là que le brevet est le plsu nuisible : breveter tout et n'importe quoi parcequ'on a les moyens financiers de le faire et ensuite viser les grosses boite avec des brevets sur des technologies qui sont depuis devenues fondamentales.
Kha
# Chronologie.
Posté par Jerome Herman . En réponse à la dépêche Microsoft et Apple poursuivis pour violation de brevet. Évalué à 10.
Lorsque l'on va sur la page du brevet on trouve des choses très interressantes dans la bibliographie.
Parmis lesquelles :
Daniels, D. and Spector, A.Z., "An Algorithm for Replicated Directories," 2.sup.nd PODC Conference Proceedings, ACM, Copyright 1983.
"Method to Control Software-Update Applications", IBM Technical Disclosure Bulletin, pp. 5059-5060, Apr. 1987.
"CompuServe Information Service: Users Guide", pp. 119-127; 153-163; 235-243; Copyright 1988.
Shafer, Steven and Thompson, Mary, "The SUP Software Upgrade Protocol", Carnegie Mellon University School of Computer Science, Sep. 7, 1989.
Au risque de citer une de mes propres posts je renvois a ce journal :
http://linuxfr.org/~quzqo/13828.html(...)
Pour ceux qui n'aiment pas les jeux de pistes un bref résumé :
- On a commencé a se poser la question du déploiement et de la mise a jour a distance en 1983. En 1987 IBM faisait une recherche sur l'ensemble des méthodes utilisables pour faire du controle de mise a jour d'applications logicielles. Compuserve mettait déjà a disposition de ses clients un système de mise a jour automatiques des paramètres de config en 1988 et en 1989 un chercheur de l'université de Carnegie Mellon jetais les bases d'un protocole de mise a jour de logiciels (qui n'a manifestement pas eu trop de succès).
Ensuite c'est BSD qui rentre dans la danse :
Les networking release de BSD 4.3 (Network1 : 1990, reno : 1990 et Network2 : juin 1991) possédaient déjà un système d'installation et de mise a jour par internet (mais non automatisés). En 1991 386/BSD est diponible exclusivement via FTP. NetBSD le premier "fork" restera sur internet exclusivement jusqu'en 1998.
Les systeme de Package utilisé actuellement date de 1994, juste après le procès USL vs BSDI and Univeristy of California (Qui ressemble a s'y méprendre au procès que SCO essaye de faire a Linux). Mais il y a eu des embryons spécialisés dès 1992 (Que l'on trouve dans les premières versions de NetBSD).
Donc la recherche sur le sujet existe depuis 1983, mais les systèmes vraiment automatisés ne se sont présentés que vers 1992-1993. Entre temps entre 1988 et 1992 il y a eu un certain nombre de systèmes qui pertmettaient des mises a jour manuelles simple avec résolution automatique des diverses dépendances.
Donc sur ce coup là c'est un peu tendu. Le brevet n'est pas trivialement absurde. Si BTG a vraiment mis au point son sytème dans les années 90-91-92 trouver un antécédent avec des fonctions similaires risque de demander un peu de recherche.
Si il y a des survivant du crétacé inférieur qui peuvent nous confirmer l'existence de systèmes de mise a jour/deploiement a distance avant 1990, merci de se faire connaitre.
Kha
[^] # Re: registereu
Posté par Jerome Herman . En réponse au journal Enregistrement des noms de domaines en .eu. Évalué à 4.
Pas encore complètement. Par contre ils auront interêt a se dépécher de reserver leur domaine le jour ou ce sera possible car il y a fort a parier que la gentille boite qui propose de s'y prendre a l'avance va décider de déposer les noms de domaine pour elle-même. Juste histoire de pouvoir squatter un peu et de faire monter les enchères...
Kha