Quand a la portabilite ca me fait bien rire, vas me faire un soft decent avec une UI qui soit portable en te limitant a POSIX...
Tout dépend de ce que tu code et de ce que tu appelle portabilité.
Personnellement je code des programmes de calculs intensifs, des gros truc de bourrins qui travaillent sur de gros volumes de données en parrallèle. Le coeur de mes programmes est parfaitement portable car écrit en C/ANSI. La couche juste au dessus qui gère le parallèlisme est aussi très portable puisqu'elle est en POSIX.
Tu peut prendre à peu près n'importe quel OS POSIX et mes programmes compilent et ce lancent sans modifications. Par contre jamais je n'irais utiliser des serveur de calculs sous windows car impossible de compiler un truc POSIX de base dessus et je serais donc obligé de recoder toute la partie multithread qui est en générale une plaie à débugger.
La couche graphique que l'on peu éventuellement mettre au dessus, je dois avouer que personnellement je m'en bas les roustons. Elle sert juste à créer des fichiers "jobs" et à afficher des fichiers de résultats pour ceux qui n'aiment pas éditer des fichiers textes. Ça peut très bien ce coder en java ou n'importe quel autre truc un peu indépendant de la platforme.
C'est peut-être un cas particulier mais il est quand même répandu et ce n'est pas pour rien que microsoft est à a traine pour tout ce qui est calcul... Personnellement, en général je m'en fous de l'OS sur lequel tourne mes prog de calcul, tout ce que je lui demande c'est d'être compatible POSIX. Le jour ou MS le fera ça ne me genera pas que l'admin installe des serveurs sous windows, en attendant...
Est-ce que tu sais ou l'on peut avoir un peu plus d'information sur ce futur 2030 programable et savoir pour quand il est prévu ?
Je possède deux 2030, un pour chez moi et un pour au boulot, mais j'envisage d'en acheter un deuxième pour chez moi. Si les nouvelles fonctions sont intéressante et si l'attente n'est pas trop longue, je patienterais bien un peu.
Aaaargh, en effet j'avais oublier les guillements. Résultat, en effet ça ne marche pas. Désolé je n'ai pas pus tester avant de poster.
Et faut pas prendre mal le "blaireau", c'était une réaction épidermique au premier fil de réponses, ou des personnes ne répondent que pour critiquer sans chercher à comprendre le sujet.
Contrairement à ce que semblent penser les blaireaux du dessus, ce que tu fait n'est pas débile du tout.
Un exemple tout simple, pour code une liste générique en C, c'est bien pratique. Imaginons une liste dont les éléments peut-être n'importe quoi mais en gardant un typage fort, donc pas de pointeur.
On fait un code qui fontion sur un type générique BIDULE avec un truc du genre
typedef struct node_s node_t;
struct node_s {
node_t *next;
BIDULE value;
};
Et ensuite, si tu as besoin d'une liste de char tu fait :
#define BIDULE char
#include <listegen.inc>
Le problème c'est quand on doit manipuler plusieur liste de type différent, il faut que les struct et les fonction aient des nom différents. Pour cela il faut utiliser l'opérateur de concaténation ##.
Dans le fichier générique tu utilise le nom générique "ajout" et une fois inclut pour un type spécifique tu utilise "ajoutchar" par exemple. (En général on fait un peut plus joli mais c'est pour l'exemple)
Et tu peut inclure le fichier aussi souvent que tu veux avec plein de type différents.
------------
Donc pour revenir à ton cas, tu peut définir un identifiant unique avec un truc de la forme "bipbip##__FILE__" par exemple si tu veux une variable global qui aie un nom différent dans chaques fichiers tu fais :
#define mavar toto##__FILE__
int mavar;
En interne dans le fichier tu utilise mavar comme nom, mais une fois passée au préprocesseur elle aurra un nom unique.
C'est vrai principalement dans le cas des générateurs congruentiels linéaires qui ont des bits de poids faible vraiment pourris. Dans le cas d'un générateur un poil plus moderne ce problème n'existe plus.
Le problème c'est que la majoritée des fonctions rand sont des GCL...
Dans le cas d'un générateur correct qui te produit des vrais entiers 32bits, si ta borne sup est relativement basse, du style 0..100, la solution du modulo est même très bonne. Elle est téoriquement biasée mais en pratique le biai est inexistant.
Le problème c'est quand ta borne est plus grande ou quand tu ne la connais pas à l'avance, dans ce cas la ça deviens plus génant et il faut utiliser de meilleure solutions.
Ce qui est important c'est de clairement cerner ses besoin. Le méthode avec rejet peuvent être andicapantes en pratique sans apporter vraiment plus de surtée.
Ue autre solution qui te garanti un temps constant est d'utiliser des rééls :
return (double)rand() / rand_max * borne_sup
a condition que borne_sup soit suffisament inferrieur à rand_max, ce qui est général est le cas puisque typiquement rand_max est égale à , 2^31, 2^32 ou 2^64 et que borne_sup est souvent relativement petit.
Non-argument. Si elles ne sont pas spécifiées, elles devraient l'être, c'est tout. Il s'agit de bon sens que de se conformer à l'implémentation de référence... Samba implémente plein de choses "non spécifiées" pour l'intérop.
Elle devrait l'être mais elles ne le sont pas ! Pourquoi ?
En attendant, l'implémentation de référence pour l'interopérabilitée c'est quoi ? Celle de OpenOffice 3.0, celle de la suite d'IBM ? Une autre ?
Le plus simple ce serait pas d'avoir un vrai standard pour pouvoir rééllement gueuler ?
Parce que c'est Microsoft, ils ont des responsabilités, tout le monde n'est pas entreprise leader du logiciel.
C'est marrant il y a des fois ou ça gueule contre le monopole de Microsoft et des fois ou le même monopole sert d'argument...
Donc l'argument reste le même, Microsoft ne fait rien de pire que les autres.
Tu parles uniquement de l'article de ce blog, il y a d'autres problèmes avec la compatibilité! Regarde les autres discussions un peu partout sur le Web avant de dire qu'ils font la même chose qu'OOo, c'est faux. Le billet de Microsoft est une réponse adhominem "vous nous accusez de pas respecter le standard, regardez IBM est pas interopérable".
Non, je parle de tous les argument qui ont été présentés sur Linuxfr. Si tu en as d'autre montre des sources.
Sauf que ici, le standard est parfaitement respecté. L'encodage différent des cellules n'apparait que dans le namespace particulier de microsoft et donc ils codent les céllules comme ils veulent.
Je dirais même que c'est bien plus intéligent de ne pas changer de codage dans ces parties la, comme ça ils utilisent le même code pour serialiser leurs formules dans ODT ou dans XLS, donc moins de risque de bug.
Il faut bien ce mettre dans le crane que les extention de microsoft sont dans un namespace différent de celui d'ODT donc ils y font ce qu'ils veulent.
Et avec un peu de bol, c'est purement temporaire le temps que le standard ODT 1.2 sortent et qu'ils l'implémentent. S'ils ne le font pas, alors là, oui, on pourra gueuler. Et on aurra raison.
Faux.
Va falloir argumenter un peu. Ce n'est pas parce que Rob Weir n'a pas voulut s'y pointer et gueuler à ce moment là, que ça ne c'est jamais produit.
Non-argument. OpenDocument est un dialecte XML qui définit une sémantique propre. Si tu ajoutes des tags et des namespaces, tu n'es plus du OpenDocument. Tu es toujours XML mais *c'est pas le but*.
Tu as vraiment compris le principe du truc ?
Dans ce cas là, il me semble que AUCUNE suite n'est actuellement capable de produire un vrai tableau ODT. A partir du moment ou tu implémente es formules tu es obligé de les stocker quelque part. Tu le fais ou ?
Si tu le fait dans le namespace ODT tu fout tout le systeme en l'air.
Si tu le fait dans un namespace séparé, c'est bien plus propre, et le jour ou la spec est complete, tu peut gentillement convertir les anciens document qui utilise l'ancien namespace vers le standard.
Au moin ici ils ne bloquent pas les évolution du format en reservant des noms dans le names space d'ODT.
Il n'est pas dans l'intérêt d'IBM de diverger du standard, parce qu'ils le soutiennent activement et veulent se positionner mieux sur le marché de la bureautique. Pour que leur stratégie marche, il est plus intéressant que de nombreux logiciels puissent interopérer sur les formats OpenDocument de la façon la plus transparente.
De quel standard parle tu ? Le débat porte sur les formules, et celle-ci ne sont spécifiées nulle part dans les specs actuelles de l'ODF.
Tu es comme d'habitude de mauvaise foi en accusant la "communauté" (au sens large) pour procès d'intention alors qu'elle a bien raison d'être doublement vigilants avec MS.
Et pourtant ici Microsoft ne fait rien de pire que les autre et ça gueule uniquement contre Microsoft. Oui, ils ont un lourd passif et il faut surveiller ce qu'ils font sans prendre leur déclaration pour argent comptant. Mais ils ne faut pas non-plus ce ridiculiser avec des acusation fausses.
MS a une part de marché bien supérieure à IBM avec Office et il s'agit de sa responsabilité en tant que bon citoyen et utilisateur du format de ne pas vendre un produit comme étant compatible OpenDocument si des erreurs peuvent être trouvées en 5 minutes. Pourquoi ne pas communiquer avec la communauté OpenDoc et leur demander de tester avant de release ?
Dans tout ce qui à été présenté jusqu'a maintenant, la norme est parfaitement respectée, contrairement à ce qui est dit. Le formules n'éxiste pas dans la norme, donc MS fait la même chose qu'OOo, ils l'implémentent de la manière la plus simple pour eux en attendant la prochaine version d'ODT. (à ce moment là on verra s'ils implémentent un support de la nouvelle norme.)
Donc pour l'instant il n'y a pas eu d'erreur trouvée en 5min, juste une grosse lacune dans la norme que chacun bouche comme il veut.
Pour la communication, Microsoft à fait une réunion avec le BB d'ODT ou ils ont expliquer tout le bordel et ou personne n'a gueulé. Ils ont donc communiqué. Pour les tests, tu peut être sûr qu'ils les ont fais, mais ils ont testé ce qui était dans le standard. Il est normal que ce que le standard ne couvre pas ne soit pas forcément compatible.
Le XML est même fait pour cela, quand tu veut ajouter des infos supplémentaire tu fait un namespace séparé.
MS aurrait pus faire bien pire : «pas de formule dans un ODT puisque ce n'est pas supporter par le standard»
Le jour ou le standard sera complet, on peut espérer que microsoft l'implémentera completement et que cela permettra de convertir les vieux documents, tout comme on peut espéré que la même chose sera faite dans les suite libres.
Si ce n'es pas le cas, on aurra une bonne raison de gueuler.
Ce qui est attendu de MS c'est d'utilisé pour odf 1.1 un namesapce compatible et de mettre des acollades là ou il faut.
Un namespace compatible avec quoi ?
Lo norme n'indique rien pour les formules !
A partir de ce moment, si tu veux respecter la norme et proposer les formules aux utilisateurs, tu doit les mettre dans un namespace different car ce que tu ajoute n'est pas la norme.
Et à partir du moment ou tu es dans ton namespace, les accolade tu ne les met que si tu veux.
Il y a surement plein de merdes bien plus pertinentes a critiquer dans l'implementation de ODF de la part de microsoft. Ressortir celle la ne fait que mettre de plus en plus en évidence la connerie monumetale qui a été faite en sortant ODF sans rien pour les formules.
En attendant, Microsoft ne fait rien de mal, ils font comme les autres : «Ils proposent la solution la plus simple a mettre en œuvre en attendant qu'une vrai norme sorte.»
Mais ils n'ont pas fait ce choix. Ils veulent le support ODF tout de suite, sans attendre la 1.2...et ce choix implique de se baser sur le standard actuel
Ce n'est pas supporter l'ODF tout de suite, c'est suporter l'ODF version 1.1. Pour la version 1.2 ça viendra peut être plus tard et, si les formules sont incluse dans le standard on pourra gueuler s'ils ne les supportent pas correctement.
En attendant, ils ont fait exactement la même chose qu'OpenOffice : la norme ne précisant pas les formules, ils ont choisit la solution la plus simple, utiliser leur représentation.
Actuellement OpenOffice ne fait qu'utiliser la représentation qui lui convient. Les autres suites utilise le même code donc elle font la même chose. Microsoft utilise un code différent mais fait la même chose : un codage au plus simple.
De ce que j'ai vu, mais je peut me tromper, il me semble même que Microsoft fait les choses plus proprement car ils utilisent un namespace différent du namespace officiel pour bien distinguer le fait que ce qu'ils stockent pour le moment n'est pas standard.
Dans tous les cas, ce débat est completement débile. Les formules ne sont pas documentée dans ODF 1.1, donc une implémentation de cette version les stocke comme elle veut.
Plutôt que de troller sur ce genre d'absurditées, il faudrait mieux ce bouger le cul pour enfin sortir un standard complet, et avoir une bonne raison pour critiquer microsoft si ils ne l'implémentent pas correctement.
Les changement dans l'algo lui même (notament les tables S) ont éffectivement amélioré l'algo. Sans ces modifications l'algo était bien moins résistant aux attaques par cryptographie différentielle, une technique d'analyse qui ne sera publiquement découverte que plusieurs années plus tard. (mais que la NSA connaissait surement déjà à l'époque...)
Par contre la réduction de la taille de la clé, elle, n'a certainement pas amélioré la sécurité offerte par DES... Bien au contraire.
Pour plus d'info, voir l'excelent livre «Applied cryptographie» de Bruce Schneier.
A en entendre certains je n'en susi pas aussi sûr que toi. Pour beaucoup, c'est tellement simple et naturel que ça ne peut être que légal. De même, certains parents sont complètement dépassés par Internet et ne savent pas que lorsque leurs enfant téléchargent de la musique sur emule ou autre c'est illégal. (sauf pour la musique libre et autres exception bien sûr...)
De même, le fait que, pour tout le monde, il semble que personne ne fait rien pour empêcher le téléchargement illégal. Il est extrèmement simple de télécharger, il n'y a aucune barrière, même le dieu google référence plein de liens pour es films et musiques. Tout cela donne l'impréssion au gens que télécharger est légal, ou au minimum toléré. Il n'y a que les fadas comme nous pour être au courrant des quelques procès qu'il y a de temps en temps.
Trÿo est bien conscient de ce problème et voit dans l'Hadoepi un moyen de prévenir les gens de manière officielle que ce qu'ils font n'est pas légal. Ils recevront un mail leur disant « Attention : ce que vous faites est illégal, cette fois ci on vous préviens gentillement car on est bien conscient que la situation ne semble pas clair pour tout le mode, maintenant vous êtes au courrant. »
Je ne dit pas qu'ils ont raison de soutenir l'hadoepi, mais je pense que leur point de vue est très pertinent. Beaucoup de gens n'ont pas réellement conscience de ce qu'ils font et si un couillons comme moi leur explique ça ne changera rien, par contre si l'explication à un caractère officiel, là ils vont réaggir.
Ce que je voulais souligner, c'est que l'angle d'attaque vis-à-vis des artistes tels que Trÿo n'est pas de dire «l'hadoepi c'est de la merde » mais « attention, en effet l'Hadoepi va faire ce que vous pensez, mais elle fera bien plus et des chose très dangeureuse. Le prix à payer n'en vaut pas le coup. Aidez nous à la rejeter, et discutons pour mettre au point une bonne solution. »
J'ai toujours exclut le critère politique dans mes choix musicaux. Bien sûr, j'ai plus de facilitées à découvrir des artistes qui ont des idées politiques qui me conviennent et je suis généralement plus réceptif à leurs textes, mais ce n'est pas parce qu'un artiste à des idées différentes des miennes que je n'écouterait pas sa mausique si elle me plait ou que je n'acheterait pas son CD.
Sinon, je crois que le nombre de produits que je pourrais acheter serait bien limité...
De plus, ce genre de listes est à prendre avec des pincettes. Quand j'ai apris que Trÿo, un groupe que j'aprécie, faisait parti des 10000 signataire soutenant Hapoepi, je suis aller faire un tour sur leur forum.
Ils sont de ces artistes qui communiquent bien avec leur publique, en ce moment par l'intermédiaire de leur producteur car ils sont en tournée et en studio. L'avantage ces de pouvoir discuter aec quelqu'un qui les connait bien et qui connait bien leur position, et qui en plus est lui même un petit producteur indépendant.
Sur leur forum, il explique que, en effet Trÿo à signer la liste, sans que ce soit un engagement profond et explique leur raisons qui sont tout à fait valable mais qui montre que leur compréhension de la loi est fortement biaisée par la manière dont elle leur a étée présenté. Il s'en suit une longue discution sur beaucoup de page, ou des gens leur expliquent les inconvéninent de la loi.
C'est un échange très intéressant et qui montre que ce n'est pas parce qu'un artiste soutient l'hadoepi qu'il a des idées différentes des notres.
Trÿo est contre le piratage et la licence globale, comme beaucoup ici.
Trÿo est contre la répréssion et les monstrueuse amende ou les procès, comme beaucoup ici.
Trÿo voit dans l'Hadoepi une loi qui va permettre de faire de l'information : Faire comprendre au gens que le téléchargement n'est pas légal.
Le problème c'est que beaucoup d'artistes sont de bonne foi (je ne parle pas de ceux qui obéissent à leur major de la même manière que les députés UMP obéissent à notre président...)
Et ils n'ont pas tord, cete loi fera surement comprendre à beaucoup de gens que en effet le téléchargement est illégal.
Ce qui est difficile c'est de leur faire comprendre tous les autres points de la loi :
- le fait qu'elle n'empeche pas une attaque classique -> on leur a promis le contraire ;
- le fait qu'elle soit liberticide -> quand on n'est pas du millieu ça fait quand même théorie du complot ;
- le fait que l'on ai aucun moyen de défence -> les défenceur ne cesse de répéter le contraire.
Ce qu'il faudrait c'est un document simple e clair, mais bien étayer avec des preuve des dangers de chacun des points. Quelque chose qui soit vraiment concret à présenter au artistes pour leur dire : « Vous avez raison, cette loi à des avantages, mais le problème c'est qu'elle à étée faite avec les pieds et qu'elle à 100 fois plus d'inconvénients, regarder ici [http://...] vous y trouver un document avec tout ce qu'il faut pour comprendre. »
Citer systématiquement alourdit la lectre de la page. C'est utile lorsque le repond à juste une partie d'un commentaire, ou lorsque l'on apporte plusieurs réponses à des parties différentes, ça aide à structurer. Mais lorsque l'on répond à un commentaire court ça gène plus que ça n'aide la lecture.
Un historique ça alourdit la charge côté serveur et c'est beaucoup plus complexe à mettre en place.
Cette utilisation «malhonete» sera peut-être rare mais elle est quand même génante. Et les utilisateurs qui la pratiquerons ne seront connus que de lecteurs les plus acharnés de linuxfr et de ce qui en aurons subis les conséquences.
Et vu la durée de vie des journaux, de quelques heures à quelques jours suivant la periode, je ne suis pas sur que ça vaille vraiment le coup de mettre en place un systeme complexe pour pas grand chose au final.
Par-ce qu'il n'y a rien de pire que de pouvoir éditer les commentaires. Ça casse le fil des discutions.
Bien sûr ça peut-être bien utilisé pour corriger les fautes d'orthographes, mais ça permet aussi de modifier un commentaire où le posteur à dit une grosse connerie et s'est fait descendre dans les réponses. Et dans ce cas les commentaires qui corrigent l'erreur se retrouve là sans que l'on comprennent pourquoi et on ne comprend plus ce qui ce passe.
Donc pour les fautes d'orthographe, on fait ce que l'on peut en se relisant, ça encourage la qualité ; et pour les conneries, on assume.
Et moi je propose de remplacer "nombre d'utilisateurs probables" par "nombre de vieux geek qui attendent des nouvelles". Et vu qu'E17 est devenu plus qu'une légende chez les vieux geeks ils gagne haut la main... (il partage la première place avec DukeNukem Forever)
Bien sûr, si on prend en compte tous les ptit jeunes qui n'on pas connu la merveille qu'est E16 et donc n'attendent rien de E17...
PS: Ce messae n'est bien entendu qu'une pause nostalgie ;-)
Oui, un acces à internet est important pour moi.
Oui, j'irais chez un hébergeur classique s'ils n'ont pas reglés leurs problème d'ici là et que je n'ai rien trouvé d'autre.
Mais, oui je préferearis trouver une hébergement tel que celui de FDN plustôt qu'un hébergeur classique.
Le truc c'est que je ne voit pas d'autres offres, donc je demandait aux LinuxFRiens qui sont en général callé dans ce genre de choses s'ils ne connaissaient pas d'autres offfres et s'il ne n'avaient pas un peu plus des infos sur les problèmes rencontrés par FDN afin de savoir si ça allait durer longtemps.
Si je ne me trompe pas, tu as le droit de faire de la retroingenieurie pour comprendre comment ça marche. Mais ça ne te donne pas le droit de modifier le driver.
Par contre avec la conaissance acquise par retroingenieurie, tu peut réécrie un driver avec les modifs que tu souhaite.
Après avoir habité dans un trou perdu en bossant pour un opérateur que je ne citerais pas et donc à tarif préférentiel, je vais très probablement émigrer sur paris d'ici peu. Je me suis donc dit que j'allais pouvoir passer à FDN pour ma ligne ADSL.
Hélas, depuis le début du mois ils n'ouvrent plus de nouvelle ligne suite à un problème avec leur grossiste. Ils indiquent qu'ils doneront plus de précisions bientôt mais toujours aucune nouvelles.
Est-ce que quelqu'un sait ce qu'il se passe et s'ils pourrons bientôt fournir à nouveau ce service ?
Et connaissez vous d'autres hébergeurs fonctionant sur le même principe ? Je me voit mal me passer trop longtemps de connexion au net, et les hébergeur classique demandent en général un engagement d'un an...
Je dois avouer justement que sur ce coup là je suis bien embeter pour choisir entre les deux. Je suis pour les logiciel libres et pour les logiciel qui prive les utilisateurs du droit de les transformer en logiciel propriétaires. Donc je suis lesdeux...
Par-ce qu'il n'y a rien de pire que de pouvoir éditer les commentaires. Ça casse le fil des discutions.
Bien sûr ça peut-être bien utilisé pour corriger les fautes d'orthographes, mais ça permet aussi de modifier un commentaire où le posteur à dit une grosse connerie et s'est fait descendre dans les réponses. Et dans ce cas les commentaires qui corrigent l'erreur se retrouve là sans que l'on comprennent pourquoi et on ne comprend plus ce qui ce passe.
Donc pour les fautes d'orthographe, on fait ce que l'on peut en se relisant, ça encourage la qualité ; et pour les conneries, on assume.
Je suis entièrement d'accord avec toi sur le fait qu'elles était vielles et obsolète, mais ces méthodes avais quand même deux très gros avantages :
- pédagogiques : elles permetait d'aprendre facilement l'OpenGL de manière explicte, le code suivant par exemple était simple à comprendre et à utiliser : glBegin(GL_TRANGLES);
glVertex3f(0.0, 0.0, 0.0);
glVertex3f(1.0, 0.0, 0.0);
glVertex3f(1.0, 1.0, 0.0);
glEnd();
Cela permettait d'entrer en douceur dans le monde d'OpenGL, de faire facilement des essais et de debuger avec beaucoup moins de soucis. Plus tard tu apprend à utiliser les array et tout ce qui va avec.
- prototypage : Ces méthodes permetait d'obtenir très rapidement et sans ce prendre la tête et visualisation 3D de n'importe quoi. Par exemple en ce moment je bosse sur un petit moteur physique pour un petit jeu et ce genre de méthodes me permet de visualiser graphiquement tous les paramètres du moteurs sans avoir à passer par des lignes de code complexes qui ne seront dévellopée que plus tard quand le moteur sera suffisament bon et que je passerais à l'aspect graphique du jeu.
En attendant un rendu super basique avec ces méthodes est largement suffisant et extrèmement simple à coder.
Donc, oui c'est une bonne chose qu'elles aient disparu de la spec, mais j'espère que l'on verra apparaitre une lib du style de glu ou de glut qui implémentera une API très simple et basique au dessus de la spec.
Enfin en attendant, il est fort probable que toutes ces méthodes restent disponible avec l'extention de compatibilité pendant au moins quelques temps. On verra plus tard.
[^] # Re: ODF et wifi
Posté par beagf (site web personnel) . En réponse au journal if (microsoft()) {kludge;}. Évalué à 10.
Tout dépend de ce que tu code et de ce que tu appelle portabilité.
Personnellement je code des programmes de calculs intensifs, des gros truc de bourrins qui travaillent sur de gros volumes de données en parrallèle. Le coeur de mes programmes est parfaitement portable car écrit en C/ANSI. La couche juste au dessus qui gère le parallèlisme est aussi très portable puisqu'elle est en POSIX.
Tu peut prendre à peu près n'importe quel OS POSIX et mes programmes compilent et ce lancent sans modifications. Par contre jamais je n'irais utiliser des serveur de calculs sous windows car impossible de compiler un truc POSIX de base dessus et je serais donc obligé de recoder toute la partie multithread qui est en générale une plaie à débugger.
La couche graphique que l'on peu éventuellement mettre au dessus, je dois avouer que personnellement je m'en bas les roustons. Elle sert juste à créer des fichiers "jobs" et à afficher des fichiers de résultats pour ceux qui n'aiment pas éditer des fichiers textes. Ça peut très bien ce coder en java ou n'importe quel autre truc un peu indépendant de la platforme.
C'est peut-être un cas particulier mais il est quand même répandu et ce n'est pas pour rien que microsoft est à a traine pour tout ce qui est calcul... Personnellement, en général je m'en fous de l'OS sur lequel tourne mes prog de calcul, tout ce que je lui demande c'est d'être compatible POSIX. Le jour ou MS le fera ça ne me genera pas que l'admin installe des serveurs sous windows, en attendant...
[^] # Re: Switch de mapping
Posté par beagf (site web personnel) . En réponse au journal 2 semaines en Typematrix Bépo. Évalué à 3.
Je possède deux 2030, un pour chez moi et un pour au boulot, mais j'envisage d'en acheter un deuxième pour chez moi. Si les nouvelles fonctions sont intéressante et si l'attente n'est pas trop longue, je patienterais bien un peu.
[^] # Re: pdf2ps & a2ps ?
Posté par beagf (site web personnel) . En réponse au message Fusionner les pages d'un pdf. Évalué à 5.
Pour fusionner les 2 pdf en un seul tu passe par pdftk :
pdftk 1.pdf 2.pdf cat output 123.pdf
Et pour faire un booklet à partir du pdf résultat tu utilises psbook qui généralement cause moins de problèmes que a2ps.
[^] # Re: Pour faire dans le constructif
Posté par beagf (site web personnel) . En réponse au message Macro pour définir identifiant uniques. Évalué à 2.
Et faut pas prendre mal le "blaireau", c'était une réaction épidermique au premier fil de réponses, ou des personnes ne répondent que pour critiquer sans chercher à comprendre le sujet.
# Pour faire dans le constructif
Posté par beagf (site web personnel) . En réponse au message Macro pour définir identifiant uniques. Évalué à 2.
Un exemple tout simple, pour code une liste générique en C, c'est bien pratique. Imaginons une liste dont les éléments peut-être n'importe quoi mais en gardant un typage fort, donc pas de pointeur.
On fait un code qui fontion sur un type générique BIDULE avec un truc du genre
typedef struct node_s node_t;
struct node_s {
node_t *next;
BIDULE value;
};
Et ensuite, si tu as besoin d'une liste de char tu fait :
#define BIDULE char
#include <listegen.inc>
Le problème c'est quand on doit manipuler plusieur liste de type différent, il faut que les struct et les fonction aient des nom différents. Pour cela il faut utiliser l'opérateur de concaténation ##.
exemple :
#define TYPE char
#include <liste.inc>
Fichier liste.inc :
#define ajout ajout##TYPE
void ajout(TYPE valeur) {...}
Dans le fichier générique tu utilise le nom générique "ajout" et une fois inclut pour un type spécifique tu utilise "ajoutchar" par exemple. (En général on fait un peut plus joli mais c'est pour l'exemple)
Et tu peut inclure le fichier aussi souvent que tu veux avec plein de type différents.
------------
Donc pour revenir à ton cas, tu peut définir un identifiant unique avec un truc de la forme "bipbip##__FILE__" par exemple si tu veux une variable global qui aie un nom différent dans chaques fichiers tu fais :
#define mavar toto##__FILE__
int mavar;
En interne dans le fichier tu utilise mavar comme nom, mais une fois passée au préprocesseur elle aurra un nom unique.
[^] # Re: .
Posté par beagf (site web personnel) . En réponse au journal Hasard 0.8 : bibliothèque de génération des nombres aléatoires. Évalué à 3.
Le problème c'est que la majoritée des fonctions rand sont des GCL...
Dans le cas d'un générateur correct qui te produit des vrais entiers 32bits, si ta borne sup est relativement basse, du style 0..100, la solution du modulo est même très bonne. Elle est téoriquement biasée mais en pratique le biai est inexistant.
Le problème c'est quand ta borne est plus grande ou quand tu ne la connais pas à l'avance, dans ce cas la ça deviens plus génant et il faut utiliser de meilleure solutions.
Ce qui est important c'est de clairement cerner ses besoin. Le méthode avec rejet peuvent être andicapantes en pratique sans apporter vraiment plus de surtée.
[^] # Re: .
Posté par beagf (site web personnel) . En réponse au journal Hasard 0.8 : bibliothèque de génération des nombres aléatoires. Évalué à 4.
return (double)rand() / rand_max * borne_sup
a condition que borne_sup soit suffisament inferrieur à rand_max, ce qui est général est le cas puisque typiquement rand_max est égale à , 2^31, 2^32 ou 2^64 et que borne_sup est souvent relativement petit.
[^] # Re: Extraordinaire !!
Posté par beagf (site web personnel) . En réponse au journal ODF et Microsoft Office 2007 SP2 (suite et surement pas fin). Évalué à 3.
Et donc une abhération de connerie de merde celon la pensée générale de site... en tout cas lorsque le standard de fait vient d'un logiciel proprio.
Un standard de fait ça n'est pas un standard.
On verra ce que ça donnera quand le standard sera publié.
[^] # Re: La route est longue, mais la voie est libre!
Posté par beagf (site web personnel) . En réponse au journal Oui je sais, on est pas Vendredi. Évalué à 4.
Elle devrait l'être mais elles ne le sont pas ! Pourquoi ?
En attendant, l'implémentation de référence pour l'interopérabilitée c'est quoi ? Celle de OpenOffice 3.0, celle de la suite d'IBM ? Une autre ?
Le plus simple ce serait pas d'avoir un vrai standard pour pouvoir rééllement gueuler ?
Parce que c'est Microsoft, ils ont des responsabilités, tout le monde n'est pas entreprise leader du logiciel.
C'est marrant il y a des fois ou ça gueule contre le monopole de Microsoft et des fois ou le même monopole sert d'argument...
Donc l'argument reste le même, Microsoft ne fait rien de pire que les autres.
Tu parles uniquement de l'article de ce blog, il y a d'autres problèmes avec la compatibilité! Regarde les autres discussions un peu partout sur le Web avant de dire qu'ils font la même chose qu'OOo, c'est faux. Le billet de Microsoft est une réponse adhominem "vous nous accusez de pas respecter le standard, regardez IBM est pas interopérable".
Non, je parle de tous les argument qui ont été présentés sur Linuxfr. Si tu en as d'autre montre des sources.
Faux encore une fois. http://www.robweir.com/blog/2009/05/follow-up-on-excel-2007-(...)
Sauf que ici, le standard est parfaitement respecté. L'encodage différent des cellules n'apparait que dans le namespace particulier de microsoft et donc ils codent les céllules comme ils veulent.
Je dirais même que c'est bien plus intéligent de ne pas changer de codage dans ces parties la, comme ça ils utilisent le même code pour serialiser leurs formules dans ODT ou dans XLS, donc moins de risque de bug.
Il faut bien ce mettre dans le crane que les extention de microsoft sont dans un namespace différent de celui d'ODT donc ils y font ce qu'ils veulent.
Et avec un peu de bol, c'est purement temporaire le temps que le standard ODT 1.2 sortent et qu'ils l'implémentent. S'ils ne le font pas, alors là, oui, on pourra gueuler. Et on aurra raison.
Faux.
Va falloir argumenter un peu. Ce n'est pas parce que Rob Weir n'a pas voulut s'y pointer et gueuler à ce moment là, que ça ne c'est jamais produit.
Non-argument. OpenDocument est un dialecte XML qui définit une sémantique propre. Si tu ajoutes des tags et des namespaces, tu n'es plus du OpenDocument. Tu es toujours XML mais *c'est pas le but*.
Tu as vraiment compris le principe du truc ?
Dans ce cas là, il me semble que AUCUNE suite n'est actuellement capable de produire un vrai tableau ODT. A partir du moment ou tu implémente es formules tu es obligé de les stocker quelque part. Tu le fais ou ?
Si tu le fait dans le namespace ODT tu fout tout le systeme en l'air.
Si tu le fait dans un namespace séparé, c'est bien plus propre, et le jour ou la spec est complete, tu peut gentillement convertir les anciens document qui utilise l'ancien namespace vers le standard.
Au moin ici ils ne bloquent pas les évolution du format en reservant des noms dans le names space d'ODT.
[^] # Re: La route est longue, mais la voie est libre!
Posté par beagf (site web personnel) . En réponse au journal Oui je sais, on est pas Vendredi. Évalué à 6.
De quel standard parle tu ? Le débat porte sur les formules, et celle-ci ne sont spécifiées nulle part dans les specs actuelles de l'ODF.
Tu es comme d'habitude de mauvaise foi en accusant la "communauté" (au sens large) pour procès d'intention alors qu'elle a bien raison d'être doublement vigilants avec MS.
Et pourtant ici Microsoft ne fait rien de pire que les autre et ça gueule uniquement contre Microsoft. Oui, ils ont un lourd passif et il faut surveiller ce qu'ils font sans prendre leur déclaration pour argent comptant. Mais ils ne faut pas non-plus ce ridiculiser avec des acusation fausses.
MS a une part de marché bien supérieure à IBM avec Office et il s'agit de sa responsabilité en tant que bon citoyen et utilisateur du format de ne pas vendre un produit comme étant compatible OpenDocument si des erreurs peuvent être trouvées en 5 minutes. Pourquoi ne pas communiquer avec la communauté OpenDoc et leur demander de tester avant de release ?
Dans tout ce qui à été présenté jusqu'a maintenant, la norme est parfaitement respectée, contrairement à ce qui est dit. Le formules n'éxiste pas dans la norme, donc MS fait la même chose qu'OOo, ils l'implémentent de la manière la plus simple pour eux en attendant la prochaine version d'ODT. (à ce moment là on verra s'ils implémentent un support de la nouvelle norme.)
Donc pour l'instant il n'y a pas eu d'erreur trouvée en 5min, juste une grosse lacune dans la norme que chacun bouche comme il veut.
Pour la communication, Microsoft à fait une réunion avec le BB d'ODT ou ils ont expliquer tout le bordel et ou personne n'a gueulé. Ils ont donc communiqué. Pour les tests, tu peut être sûr qu'ils les ont fais, mais ils ont testé ce qui était dans le standard. Il est normal que ce que le standard ne couvre pas ne soit pas forcément compatible.
Le XML est même fait pour cela, quand tu veut ajouter des infos supplémentaire tu fait un namespace séparé.
MS aurrait pus faire bien pire : «pas de formule dans un ODT puisque ce n'est pas supporter par le standard»
Le jour ou le standard sera complet, on peut espérer que microsoft l'implémentera completement et que cela permettra de convertir les vieux documents, tout comme on peut espéré que la même chose sera faite dans les suite libres.
Si ce n'es pas le cas, on aurra une bonne raison de gueuler.
[^] # Re: C'est pas un peu le cas du DivX ?
Posté par beagf (site web personnel) . En réponse au journal Oui je sais, on est pas Vendredi. Évalué à 4.
Un namespace compatible avec quoi ?
Lo norme n'indique rien pour les formules !
A partir de ce moment, si tu veux respecter la norme et proposer les formules aux utilisateurs, tu doit les mettre dans un namespace different car ce que tu ajoute n'est pas la norme.
Et à partir du moment ou tu es dans ton namespace, les accolade tu ne les met que si tu veux.
Il y a surement plein de merdes bien plus pertinentes a critiquer dans l'implementation de ODF de la part de microsoft. Ressortir celle la ne fait que mettre de plus en plus en évidence la connerie monumetale qui a été faite en sortant ODF sans rien pour les formules.
En attendant, Microsoft ne fait rien de mal, ils font comme les autres : «Ils proposent la solution la plus simple a mettre en œuvre en attendant qu'une vrai norme sorte.»
[^] # Re: Extraordinaire !!
Posté par beagf (site web personnel) . En réponse au journal ODF et Microsoft Office 2007 SP2 (suite et surement pas fin). Évalué à 2.
Ce n'est pas supporter l'ODF tout de suite, c'est suporter l'ODF version 1.1. Pour la version 1.2 ça viendra peut être plus tard et, si les formules sont incluse dans le standard on pourra gueuler s'ils ne les supportent pas correctement.
En attendant, ils ont fait exactement la même chose qu'OpenOffice : la norme ne précisant pas les formules, ils ont choisit la solution la plus simple, utiliser leur représentation.
Actuellement OpenOffice ne fait qu'utiliser la représentation qui lui convient. Les autres suites utilise le même code donc elle font la même chose. Microsoft utilise un code différent mais fait la même chose : un codage au plus simple.
De ce que j'ai vu, mais je peut me tromper, il me semble même que Microsoft fait les choses plus proprement car ils utilisent un namespace différent du namespace officiel pour bien distinguer le fait que ce qu'ils stockent pour le moment n'est pas standard.
Dans tous les cas, ce débat est completement débile. Les formules ne sont pas documentée dans ODF 1.1, donc une implémentation de cette version les stocke comme elle veut.
Plutôt que de troller sur ce genre d'absurditées, il faudrait mieux ce bouger le cul pour enfin sortir un standard complet, et avoir une bonne raison pour critiquer microsoft si ils ne l'implémentent pas correctement.
[^] # Re: Demande de rançon
Posté par beagf (site web personnel) . En réponse au journal 10 millions ou vous ne reverrez jamais vos données !. Évalué à 5.
Par contre la réduction de la taille de la clé, elle, n'a certainement pas amélioré la sécurité offerte par DES... Bien au contraire.
Pour plus d'info, voir l'excelent livre «Applied cryptographie» de Bruce Schneier.
[^] # Re: Boycott
Posté par beagf (site web personnel) . En réponse au journal Les artistes de gauche pour la loi HADOPI. Évalué à 1.
De même, le fait que, pour tout le monde, il semble que personne ne fait rien pour empêcher le téléchargement illégal. Il est extrèmement simple de télécharger, il n'y a aucune barrière, même le dieu google référence plein de liens pour es films et musiques. Tout cela donne l'impréssion au gens que télécharger est légal, ou au minimum toléré. Il n'y a que les fadas comme nous pour être au courrant des quelques procès qu'il y a de temps en temps.
Trÿo est bien conscient de ce problème et voit dans l'Hadoepi un moyen de prévenir les gens de manière officielle que ce qu'ils font n'est pas légal. Ils recevront un mail leur disant « Attention : ce que vous faites est illégal, cette fois ci on vous préviens gentillement car on est bien conscient que la situation ne semble pas clair pour tout le mode, maintenant vous êtes au courrant. »
Je ne dit pas qu'ils ont raison de soutenir l'hadoepi, mais je pense que leur point de vue est très pertinent. Beaucoup de gens n'ont pas réellement conscience de ce qu'ils font et si un couillons comme moi leur explique ça ne changera rien, par contre si l'explication à un caractère officiel, là ils vont réaggir.
Ce que je voulais souligner, c'est que l'angle d'attaque vis-à-vis des artistes tels que Trÿo n'est pas de dire «l'hadoepi c'est de la merde » mais « attention, en effet l'Hadoepi va faire ce que vous pensez, mais elle fera bien plus et des chose très dangeureuse. Le prix à payer n'en vaut pas le coup. Aidez nous à la rejeter, et discutons pour mettre au point une bonne solution. »
[^] # Re: Boycott
Posté par beagf (site web personnel) . En réponse au journal Les artistes de gauche pour la loi HADOPI. Évalué à 4.
Sinon, je crois que le nombre de produits que je pourrais acheter serait bien limité...
De plus, ce genre de listes est à prendre avec des pincettes. Quand j'ai apris que Trÿo, un groupe que j'aprécie, faisait parti des 10000 signataire soutenant Hapoepi, je suis aller faire un tour sur leur forum.
Ils sont de ces artistes qui communiquent bien avec leur publique, en ce moment par l'intermédiaire de leur producteur car ils sont en tournée et en studio. L'avantage ces de pouvoir discuter aec quelqu'un qui les connait bien et qui connait bien leur position, et qui en plus est lui même un petit producteur indépendant.
Sur leur forum, il explique que, en effet Trÿo à signer la liste, sans que ce soit un engagement profond et explique leur raisons qui sont tout à fait valable mais qui montre que leur compréhension de la loi est fortement biaisée par la manière dont elle leur a étée présenté. Il s'en suit une longue discution sur beaucoup de page, ou des gens leur expliquent les inconvéninent de la loi.
C'est un échange très intéressant et qui montre que ce n'est pas parce qu'un artiste soutient l'hadoepi qu'il a des idées différentes des notres.
Trÿo est contre le piratage et la licence globale, comme beaucoup ici.
Trÿo est contre la répréssion et les monstrueuse amende ou les procès, comme beaucoup ici.
Trÿo voit dans l'Hadoepi une loi qui va permettre de faire de l'information : Faire comprendre au gens que le téléchargement n'est pas légal.
Le problème c'est que beaucoup d'artistes sont de bonne foi (je ne parle pas de ceux qui obéissent à leur major de la même manière que les députés UMP obéissent à notre président...)
Et ils n'ont pas tord, cete loi fera surement comprendre à beaucoup de gens que en effet le téléchargement est illégal.
Ce qui est difficile c'est de leur faire comprendre tous les autres points de la loi :
- le fait qu'elle n'empeche pas une attaque classique -> on leur a promis le contraire ;
- le fait qu'elle soit liberticide -> quand on n'est pas du millieu ça fait quand même théorie du complot ;
- le fait que l'on ai aucun moyen de défence -> les défenceur ne cesse de répéter le contraire.
Ce qu'il faudrait c'est un document simple e clair, mais bien étayer avec des preuve des dangers de chacun des points. Quelque chose qui soit vraiment concret à présenter au artistes pour leur dire : « Vous avez raison, cette loi à des avantages, mais le problème c'est qu'elle à étée faite avec les pieds et qu'elle à 100 fois plus d'inconvénients, regarder ici [http://...] vous y trouver un document avec tout ce qu'il faut pour comprendre. »
[^] # Re: Vote
Posté par beagf (site web personnel) . En réponse au journal Un bug de dlfp assez frustrant.. Évalué à 2.
Un historique ça alourdit la charge côté serveur et c'est beaucoup plus complexe à mettre en place.
Cette utilisation «malhonete» sera peut-être rare mais elle est quand même génante. Et les utilisateurs qui la pratiquerons ne seront connus que de lecteurs les plus acharnés de linuxfr et de ce qui en aurons subis les conséquences.
Et vu la durée de vie des journaux, de quelques heures à quelques jours suivant la periode, je ne suis pas sur que ça vaille vraiment le coup de mettre en place un systeme complexe pour pas grand chose au final.
[^] # Re: Vote
Posté par beagf (site web personnel) . En réponse au journal Un bug de dlfp assez frustrant.. Évalué à 7.
Par-ce qu'il n'y a rien de pire que de pouvoir éditer les commentaires. Ça casse le fil des discutions.
Bien sûr ça peut-être bien utilisé pour corriger les fautes d'orthographes, mais ça permet aussi de modifier un commentaire où le posteur à dit une grosse connerie et s'est fait descendre dans les réponses. Et dans ce cas les commentaires qui corrigent l'erreur se retrouve là sans que l'on comprennent pourquoi et on ne comprend plus ce qui ce passe.
Donc pour les fautes d'orthographe, on fait ce que l'on peut en se relisant, ça encourage la qualité ; et pour les conneries, on assume.
[^] # Re: Annonce d'une version alpha ?
Posté par beagf (site web personnel) . En réponse à la dépêche E17 est annoncé.. Évalué à 9.
Bien sûr, si on prend en compte tous les ptit jeunes qui n'on pas connu la merveille qu'est E16 et donc n'attendent rien de E17...
PS: Ce messae n'est bien entendu qu'une pause nostalgie ;-)
[^] # Re: A propos de FDN et autres
Posté par beagf (site web personnel) . En réponse au journal Nouvelles de toile libre, l'hébergeur à prix libre .. Évalué à 1.
Oui, j'irais chez un hébergeur classique s'ils n'ont pas reglés leurs problème d'ici là et que je n'ai rien trouvé d'autre.
Mais, oui je préferearis trouver une hébergement tel que celui de FDN plustôt qu'un hébergeur classique.
Le truc c'est que je ne voit pas d'autres offres, donc je demandait aux LinuxFRiens qui sont en général callé dans ce genre de choses s'ils ne connaissaient pas d'autres offfres et s'il ne n'avaient pas un peu plus des infos sur les problèmes rencontrés par FDN afin de savoir si ça allait durer longtemps.
Mais merci pour ta contribution constructive.
[^] # Re: Tu sais lire l'anglais ?
Posté par beagf (site web personnel) . En réponse au journal fglrx on a real-time kernel. Évalué à 3.
Par contre avec la conaissance acquise par retroingenieurie, tu peut réécrie un driver avec les modifs que tu souhaite.
# A propos de FDN et autres
Posté par beagf (site web personnel) . En réponse au journal Nouvelles de toile libre, l'hébergeur à prix libre .. Évalué à 5.
Hélas, depuis le début du mois ils n'ouvrent plus de nouvelle ligne suite à un problème avec leur grossiste. Ils indiquent qu'ils doneront plus de précisions bientôt mais toujours aucune nouvelles.
Est-ce que quelqu'un sait ce qu'il se passe et s'ils pourrons bientôt fournir à nouveau ce service ?
Et connaissez vous d'autres hébergeurs fonctionant sur le même principe ? Je me voit mal me passer trop longtemps de connexion au net, et les hébergeur classique demandent en général un engagement d'un an...
[^] # Re: priviste ?
Posté par beagf (site web personnel) . En réponse au journal Sondage. Évalué à 6.
Je dois avouer justement que sur ce coup là je suis bien embeter pour choisir entre les deux. Je suis pour les logiciel libres et pour les logiciel qui prive les utilisateurs du droit de les transformer en logiciel propriétaires. Donc je suis lesdeux...
[^] # Re: Graphismes relatifs
Posté par beagf (site web personnel) . En réponse à la dépêche Nexuiz 2.5 est arrivé !. Évalué à 10.
Bien sûr ça peut-être bien utilisé pour corriger les fautes d'orthographes, mais ça permet aussi de modifier un commentaire où le posteur à dit une grosse connerie et s'est fait descendre dans les réponses. Et dans ce cas les commentaires qui corrigent l'erreur se retrouve là sans que l'on comprennent pourquoi et on ne comprend plus ce qui ce passe.
Donc pour les fautes d'orthographe, on fait ce que l'on peut en se relisant, ça encourage la qualité ; et pour les conneries, on assume.
[^] # Re: Responsable
Posté par beagf (site web personnel) . En réponse au journal Le bourreau était le coupable.... Évalué à 8.
C'est bien là tout le problème.
[^] # Re: Enfin !
Posté par beagf (site web personnel) . En réponse à la dépêche Spécifications OpenGL 3.1. Évalué à 10.
- pédagogiques : elles permetait d'aprendre facilement l'OpenGL de manière explicte, le code suivant par exemple était simple à comprendre et à utiliser :
glBegin(GL_TRANGLES);glVertex3f(0.0, 0.0, 0.0);
glVertex3f(1.0, 0.0, 0.0);
glVertex3f(1.0, 1.0, 0.0);
glEnd();
Cela permettait d'entrer en douceur dans le monde d'OpenGL, de faire facilement des essais et de debuger avec beaucoup moins de soucis. Plus tard tu apprend à utiliser les array et tout ce qui va avec.
- prototypage : Ces méthodes permetait d'obtenir très rapidement et sans ce prendre la tête et visualisation 3D de n'importe quoi. Par exemple en ce moment je bosse sur un petit moteur physique pour un petit jeu et ce genre de méthodes me permet de visualiser graphiquement tous les paramètres du moteurs sans avoir à passer par des lignes de code complexes qui ne seront dévellopée que plus tard quand le moteur sera suffisament bon et que je passerais à l'aspect graphique du jeu.
En attendant un rendu super basique avec ces méthodes est largement suffisant et extrèmement simple à coder.
Donc, oui c'est une bonne chose qu'elles aient disparu de la spec, mais j'espère que l'on verra apparaitre une lib du style de glu ou de glut qui implémentera une API très simple et basique au dessus de la spec.
Enfin en attendant, il est fort probable que toutes ces méthodes restent disponible avec l'extention de compatibilité pendant au moins quelques temps. On verra plus tard.