Ce qui fait le charme de LinuxFR c'est justement son manque de neutralité et la proportion de trolls qui en découlent
Il voulait sans doute parler de neutralité "en moyenne". En effet, toutes les opinions sont représentées dans un troll en règle ! Et rien n'empêche de lancer des contre-trolls, des pièges à trolls, des attrape-trolls ...
Avec Firefox, j'utilise User Agent Switcher, une extension qu'on trouve sur Mozilla Update. Et quand il est resté réglé sur IE, je me paye des "il faut ActiveX" quand je pertinente un post ici ...
En Suisse le réseau des chemin de Fer fonctionne a 15 000v et 16 2/3 Hz de ce fait vous pouvez pas injecter directement du courant depuis le réseau civil (50Hz).
Je ne savais pas que les Anglais avaient mis au point les chemins de fer Helvétiques ... parce que pour utiliser une fréquence de 16,6666... Hz, il faut vraiment avoir été élevé avec le système impérial ;-) http://en.wikipedia.org/wiki/Imperial_unit(...)
Quelqu'un peut-il éclairer ma lanterne sur la raison de cette valeur ?
Je sais que dans les avions le courant est en 400Hz pour réduire la taille et le poids des transformateurs, mais pour le train ca n'a sans doute rien à voir.
En fait la freebox, qui tourne sous Linux je crois, ne nous appartient pas. [...]
on ne distribue pas, donc on est pas soumis aux clauses GPL concernant la distribution.
Free fait sans doute des modifications sur les logiciels libres qui tournent sur la Freebox (architecture MIPS il me semble), et j'ignore si ils envoient des patches aux développeurs quand ils trouvent un bug.
La GPL dit que l'utilisateur du logiciel libre doit avoir accès aux mêmes libertés que celui qui le lui fournit.
La question est sur la définition d'"utilisateur". Soit c'est Free, en tant que propriétaire de la Freebox et opérateur du transfert d'informations, soit c'est le client final en tant que destinataire des services offerts par les logiciels libres.
Est-on utilisateur de VLC quand on branche une TV sur une Freebox ?
Est-on utilisateur de iptables quand on choisit les règles du routeur sur le site de Free ?
Ou est-on juste "utilisateur^Wclient de l'utilisateur" ?
Y'a pas d'entrée vidéo sur la freebox ca risque pas :)
Ben si, il y a une péritel. Donc entrée/sortie
La norme Péritel supporte effectivement les signaux (RGB, composite et son) dans les 2 sens, mais qu'est-ce qui nous prouve que les entrées sont bien connectées dans la Freebox ? Pour en savoir plus il faudrait que je l'ouvre ...
Cette option de "passerelle multimédia" est assez intéressante, ca peut remplacer lirc + sortie TV [ composite :-( ] + son numérique jusqu'à la chaîne ... ou encore concurrencer les lecteurs DVD/DivX/MP3 de salon. En Wifi ca doit être assez magique.
Par contre, si ca c'est possible, je suis sûr que l'inverse aussi (et ca me serait plus utile puisque je n'ai pas de TV) : envoyer le flux TV en numérique vers le PC, pour affichage sur le moniteur. Mais il y a sans doute des pb de droits/redevance ...
En tout cas, si les interfaces de programmation sont dispo, il va sûrement y avoir plein de nouvelles idées à suivre ;-)
Finalement, le principe du brevet est bon [excepté bien sûr les tentatives actuelles de brevetage des idées], mais le problème est que la durée de validité du brevet est désespérément rigide.
20 ans, c'est relativement logique pour une industrie lourde. C'est un peu court pour les industries pharmaceutiques (encore que, pour les malades c'est bien trop long ...). Et c'est une éternité en électronique et en informatique (rappel de la loi de Moore : x2 tous les 18 mois).
Je vais donc faire une proposition d'artilleur (ou de débianeux) : le brevet doit être valide un certain temps. Et ce temps serait variable selon les cas, selon les domaines, selon l'âge du Capitaine. Je le définirais bien comme "le temps nécessaire pour rembourser l'investissement" des recherches ayant abouti à l'invention. On considère alors que la société ne gagne de l'argent que sur les services associés à l'invention, et qu'une fois la concurrence rétablie elle part avec plus d'expérience et la confiance des clients. C'est déjà une bonne récompense pour l'effort de recherche.
La durée en question serait de qq 10 années pour les procédés mécaniques ou chimiques, qq années ou qq mois pour "les inventions assistées par ordinateur", et qq heures ou qq minutes pour les algorithmes, les idées, les poèmes ...
Par contre, comment juger de manière fiable, impartiale et efficace de cette durée de validité ? Et surtout, comment la faire respecter ?
Pour choisir parmi les nombreuses méthodes possibles, il faut savoir de quoi tu as le plus besoin.
- si c'est la rapidité, alors il vaut mieux faire une LUT de 256 valeurs, c'est encore ce qui s'exécutera le plus vite. Par contre ca consomme un peu plus de mémoire (ca peut avoir son importance sur un petit CPU embarqué).
- si c'est la simplicité, et la taille de code (en mémoire) qui est recherchée, la méthode par décalage est très bien.
- certains CPU ont des instructions assembleur SWAP concues pour ca. Par contre, adieu la portabilité de ton code.
- si on a une vraie rotation de bits (pas juste un décalage avec perte du bit qui dépasse, mais généralement ca va nous ramener aussi à de l'assembleur) on peut faire ce genre de choses :
Si on décompose, ca fait :
000E 000A
H000 D000
00F0 00B0
0G00 0C00
-----------------
HGFE DCBA
Avantages : aucun test, aucune boucle, et on traite 2 bits à chaque fois.
Inconvénients : les constantes (mais sur un RISC elles sont mises avec l'instruction), la rotation qui n'est pas équivalente au décalage en C
Ben oui, au départ Windows est juste une interface graphique pour DOS.
Bon, maintenant c'est un peu différent, noyau NT toussa, mais je suis sûr qu'il reste une bonne partie des lignes de code du DOS d'origine dans NT 5.1 (aka XP). Qqun a les sources pour vérifier ?
Dans le cadre d'une TPE, avec une poignée de postes clients et un seul serveur-qui-fait-tout (firewall, proxy, serveur web, mail, groupware), est-ce qu'il n'y aurait pas des solutions de sauvegarde distribuée ?
Je n'en ai jamais entendu parler, mais est-ce qu'il serait possible de faire une sorte de RAID à travers le réseau, de manière à sauvegarder une (petite) partie du disque de chaque machine sur toutes les autres ? Les tailles de disques sont très généreuses aujourd'hui, et on va avoir du mal à remplir des centaines de Go avec des mails, des tableaux de compta, des plannings et des devis ... On pourrait imaginer une petite partition sur chaque poste client, qui reçoit la garde d'un lot de données des autres postes clients et du serveur.
Finalement, ca ressemble à certains réseaux P2P où chacun ignore ce qui est stocké sur son disque (là c'est pour pouvoir dire "j'y suis pour rien M'sieur l'Juge"), par conséquent ca ne devrait pas poser trop de pb techniques. De plus, sur un réseau local la bande passante devrait être plutôt bonne.
Evidemment, cela ne répond qu'aux pb de type "un seul disque dur cassé", si jamais le local brûle il faut de toute façon avoir une autre sauvegarde en lieu sûr.
Je ne comprends pas trop pourquoi les éditeurs de logiciels propriétaires[*] sous Linux "certifient" des distributions entières. En plus il s'agit souvent de distributions payantes et un peu anciennes (RH 8 ou 9 notamment), bonjour le support du matériel récent et la sécurité.
D'abord, quelle partie de la distrib' certifiée pour le produit en question : le minimum-sans-X, l'install desktop par défaut (avec aucun daemon lancé), les 14 CD de sources au complet ? Si il y a plusieurs versions officielles de noyau dans cette release ?
Qu'est-ce qui garantit qu'une mise à jour de sécurité ou l'installation d'un autre paquet qui ne faisait pas partie de l'install certifiée ne va pas tout casser ? Et qu'est-ce qui fait croire qu'il peut y avoir un tel risque ? Quand on liste les prérequis sous Windows, on ne dit pas "nécessite Office 2003", ou "incompatible avec Quake III", on ne parle que de l'OS, de la mémoire et du disque dur ! Le reste, c'est la hotline qui se débrouille.
Je pense qu'il serait bcp plus pertinent de lister précisément les dépendances importantes. Je suis sûr qu'il n'y en a pas tant que ca, si ils veulent garder des secrets de fabrication ils incluent de toute façon des libs statiques. Généralement, ca va être des versions minimum de noyau, de libc, de toolkit graphique, et de deux ou trois outils spécifiques. Les outils de base (shell, API réseau, langages interprétés ...) sont très stables et ne posent pas de pb de compatibilité ascendante.
Par exemple, une appli proprio peut réclamer : "noyau 2.6.5 ou suivant (avec modules réseau et RAID activés), libc6 version x.y.z ou +, gtk X.Y mais surtout pas X.Z, perl 3 ou +, incompatibilité avec le paquet trucmuche de la version 0.0.8 à la version 0.1.4 ...
Au fait, les distribs Fedora >2, Mandake 10.*, debian sarge et LFS 2.0 ont les paquets correspondant à ces critères." On me souffle dans l'oreillette que apt-get, urpmi, yum et yast sauraient même gérer les dépendances ...
Ce ne serait pas beaucoup plus difficile à tester pour l'éditeur, et au moins on sait vraiment de quoi on parle. On garde ainsi le choix de la distrib selon sa propre préférence (voire des choix officiels de l'entreprise), on n'est pas liés à un éditeur d'OS (ce qui est un des arguments forts des logiciels libres, non ? OK, si c'est pour une appli proprio c'est déjà raté), et surtout on garde la possibilité d'évoluer !
Ou alors j'ai raté un épisode ?
[*] Je pense surtout aux logiciels de CAO, traditionnellement UNIX et progressivement portés sous Linux ces temps-ci.
Ils n'y pas de souris dans l'Airbus A380?
Y'a un trackball à côté de la manette des gaz.
Et je vous assure qu'il n'y a malheureusement pas un seul pingouin dans les systèmes de pilotage : pour cela il faudrait passer une terrible certification (norme DO178B par exemple) dont le coût est hors de portée des développeurs de logiciels libres ...
(à vrai dire, il faut même commencer par certifier le compilateur !)
Ben, non !
Il n'y a bien qu'un digit d'écart, car l'un s'appelle en vrai Windows NT 5.0, et l'autre est bel et bien Windows NT 5.1.
C'est d'ailleurs rigolo quand on les appelle comme ca, et que le windozien de base rétorque "mais non, tu vois bien que c'est XP", et qu'un petit coup de demarrer->paramètres->système lui cloue le bec.
<mode troll = on> Fortran reste le langage de référence pour faire du code de calcul optimisé. Dans mon travail les temps de calculs se comptent régulièrement en semaines...
Ben c'est ptêt pour ca ...
< /mode >
En vrai, je ne sais absolument pas ce que le Fortran a de plus que les autres langages pour le calcul scientifique, je sais juste que c'est le plus vieux langage "de haut niveau" (c'est à dire pas assembleur), et qu'à ce titre c'est le seul connu de certains directeurs fossilisés. J'espère que la réciproque n'est pas vraie.
Je vote pour :
bête fichier binaire 2 fois plus gros qui contient 2 versions binaires du code compilés pour le coup 2 fois en 2 fois plus de temps
parce que c'est déjà ce qu'ils avaient fait lors du passage du 680x0 au PPC.
D'ailleurs, cette précedente transition avait été franchement bien menée, notamment parce que l'émulation du 68k par le PPC était très efficace (plus que le 68k natif il me semble). De plus, je crois que la compatibilité 68k n'a été cassée que avec MacOS X (ou peut-être le 9, qui n'était pas censé exister initialement).
Concernant le pb d'endianness (qui ne s'était pas posé à l'époque, le 68k est big-endian aussi), comment vous faites pour faire des champs de bits portables en C ? De mémoire [inversion possible] on peut faire comme ca mais c'est pas top :
#ifdef little_endian
typedef struct{
int champ1: 8;
int champ2: 2;
int reserved: 22;
}toto
#else /* big_endian*/
typedef struct{
int reserved: 22;
int champ2: 2;
int champ1: 8;
}toto
#endif
Juste deux petites remarques :
- Tu gagnerais du temps en améliorant ce qui existe déjà. Je n'ai pas fait gaffe aux détails de licences, certaines sont sous GFDL, mais à priori dans tous les cas c'est fait pour être diffusé et amélioré.
- en recto-verso c'est plus pratique, comme il y a plus de place on peut écrire plus gros ou mettre encore plus de choses.
Bon, j'arrête de critiquer, elles sont très bien tes refcards, c'est du bon boulot ! Je crois que je vais en laisser qqunes dans la photocopieuse lundi, pour faire de la pub aux licences CC ;-)
dans une communaute de quelle taille ?
Justement, c'est la question que je pose juste après ...
ceux qui ne passent pas au libre, on s'en fout, ils ont deja achete leur cam pour windows
La question qu'on peut se poser, c'est la raison qu'ont ceux qui restent avec un système onéreux, buggé et liberticide alors que l'alternative existe. Il y a entre autre le manque d'information/pub, la réticence au changement, les formats fermés et effectivement le manque de support pour certains périphériques.
Je considère qu'on ne s'en fout absolument pas, et qu'il y a sans doute des gens qui n'utilisent pas Linux juste parceque leur webcam ne marche pas avec ! Tu essayes de promouvoir les logiciels libres, ou de faire fuir les newbies ?
trop peu nombreux, sinon philips et ses potes ne cracheraient pas sur leur argent.
[Ca me rappelle la devise du Virus Informatique. 50G mouches ne peuvent pas _toutes_ avoir tort !]
Là aussi, qu'est-ce qui prouve que leur estimation du marché est juste ? Le nombre d'utilisateurs de Linux est bien moins facile à mesurer que les profits de M$ ! Et ces paramètres sont liés : si les fabricants étaient plus coopératifs, ca encouragerait les gens à utiliser les logiciels libres, et réciproquement.
Pour un groupe de rock, on appelle ca un "backdrop" il me semble. Oui, c'est bien ca, le truc "qui pend derrière" la scène, souvent un simple drap avec un logo peint à la bombe ...
En français, et avec un peu d'imagination, ca pourrait se traduire par étandard, non ?
Le jour ou linux atteint un seuil critique, il libere son pilote, laisse les devel du libre le porter
Le problème, c'est pourquoi attendre un "seuil critique" ?
Publier des specs n'est pas un travail énorme (comparé au développement lui-même, et dans la mesure où ces specs existent forcément en interne) et effectivement la communauté fera le boulot. Elle le fera de toute façon si elle en a vraiment besoin, mais la grosse différence c'est l'image de marque du constructeur (surtout si "il renvoie chier les linuxiens"). Je pense que les constructeurs sous-estiment la communication dans la communauté, une bonne ou une mauvaise pub circule très vite (à la vitesse du troll au galop, en fait).
En ce qui concerne les concurrents qui auraient ainsi accès au design, ne vous en faites pas, ils l'ont déjà : eux aussi ils font du reverse-engineering, et pas avec des moyens amateurs.
Quant à savoir si c'est rentable, encore faudrait-il avoir des chiffes fiables concernant le nombre d'utilisateurs de GNU/Linux (et BSD, Hurd, Minix ...) pour parler de parts de marché, et prendre en compte tous ceux qui ne passent pas au Libre parce que leur périphérique chéri n'est pas (bien) supporté ...
Finalement, je ne sais pas si "malin" est le bon adjectif ...
Je suis globalement d'accord avec toi. Je veux être sûr que j'ai bien compris :
On peut recopier l'effet d'un programme
Il s'agit donc de copier l'algorithme, et d'en faire une nouvelle implémentation. C'est l'implémentation qui est protégée par le droit d'auteur, pas l'algo qui lui n'appartient à personne (formule mathématique, patrimoine de l'humanité, toussa).
Enfin, tant qu'il n'y a pas de brevets sur les logiciels. :-/
Un reverse-engineering par analyse des entrées/sorties de la boîte noire (façon Tridge pour Samba) est donc acceptable.
Mais on ne peut pas plagier un programme
Là où c'est difficile, c'est de faire la distinction entre une implémentation "sincère" de l'algo, qui ressemble à l'implémentation protégée juste parce qu'il était logique de faire comme ca (structures de données classiques, nommage explicite, ...), et un repompage intégral avec "obfuscation" et mauvaise foi.
Un reverse-engineering par décompilation permet de faire l'un ou l'autre, selon l'effort et l'intelligence qu'on met dans la compréhension (abstraction) et la re-création (implémentation) du programme.
Pour reprendre l'exemple littéraire, si j'invente un super-pipotron avec analyse sémantique et générateur de synonymes, et que j'y passe un roman célèbre, ce sera toujours la même histoire, juste avec des mots différents. C'est clairement un plagiat, je n'ai pas crée de contenu culturel. (quoique, un bô pipotron comme ca, c'est pas simple à faire et ca intéresserait sûrement les hommes politiques ...)
Maintenant, si je mixe plusieurs romans sur le même thème, ou que je réécris des passages pour brouiller les pistes, que j'influe sur le style ou le vocabulaire utilisé par le programme, à partir de quel moment cela devient-il une oeuvre originale ? Comment faire la différence avec une simple "inspiration", une référence culturelle ? Si je réécris un San-Antonio avec le vocabulaire de Molière (ou l'inverse, c'est vous qui voyez) est-ce encore la même oeuvre?
L'exemple marche aussi pour la musique, avec l'échantillonnage (sample), les remixes et autres reprises (dont certaines sont créditées en tant que thème "traditionnel" pour ne pas reverser de droits).
Finalement, c'est encore l'autorisation (ou non) des travaux dérivés par les licences Creative Commons qui est la plus claire ...
C'est génial ces "souris 3D", mais je crois que le prix doit être proportionnel à ceux des softs de CAO (proprétaires) utilisés ...
On ne pourrait pas faire le même genre de choses avec un simple joystick, un modèle ambidextre pour l'utiliser avec la main qui ne tient pas la souris, et qui gère la rotation du manche ? Ils se branchent tous en USB maintenant, on devrait pouvoir gérer sans trop de mal plusieurs périphériques d'entrée.
Et pourquoi pas aussi des pédales de volant-pour-jeu-de-bagnole, toujours en USB, histoire de se muscler un peu les chevilles et de pouvoir enfin faire des raccourcis clavier sous Emacs ;-)
Les "screenchoutes" de Gnome et KDE sont là pour illustrer l'état de l'art, M$ brevetant un truc un peu différent (en gros, la vue miniature de tous les bureaux, mais maximisée sur tout l'écran).
Je ne vois quand même pas où est la nouveauté là-dedans ...
Pour le LEON, il est utilisable si tu veux. Il a du être fondu 4/5 fois déjà.
Bien plus que ca à mon avis (mais ce n'est pas toujours marqué en grand sur la puce ! ). Il suffit de voir que Jiri Gaisler arrive à en vivre ...
J'ai fait une éval d'une puce qui contenait plusieurs LEON, et c'est un bon p'tit proc. Je dis "p'tit", car comme il est très configurable, le fabricant avait choisi une implémentation minimale : pas de FPU, pas de MMU, pas de division, pas de PCI ni Ethernet ... et pour cette application ca se comprend.
Avec toutes ces options, on fait tourner Linux, eCOS ou Solaris sur ce CPU compatible SPARC sans pb.
On peut aussi l'impanter sur un FPGA (circuit logique programmable), avec l'inconvénient d'une fréquence moindre, mais l'avantage d'être reconfigurable et de pouvoir développer des coprocesseurs ...
Juste un petit bémol : le code VHDL du CPU est libre, les outils de développement "de base" (compilo, débugger ...) sont libres, mais les outils "haut niveau", notamment le simulateur TSIM, sont propriétaires et onéreux (cf. deuxième phrase de ce post). Quant à la version du CPU durcie aux radiations, je pense que ca ne concerne pas bcp de monde ici ;-)
[^] # Re: Heuresement ....
Posté par Jimmy . En réponse au journal La neutralité dans les sites web.... Évalué à 4.
Il voulait sans doute parler de neutralité "en moyenne". En effet, toutes les opinions sont représentées dans un troll en règle ! Et rien n'empêche de lancer des contre-trolls, des pièges à trolls, des attrape-trolls ...
[^] # Re: Mon avis
Posté par Jimmy . En réponse au journal La neutralité dans les sites web.... Évalué à 6.
Avec Firefox, j'utilise User Agent Switcher, une extension qu'on trouve sur Mozilla Update. Et quand il est resté réglé sur IE, je me paye des "il faut ActiveX" quand je pertinente un post ici ...
[^] # Re: J'ai eu du bol
Posté par Jimmy . En réponse au journal Tout le monde aux fenêtres, pas de maison!. Évalué à 2.
Je ne savais pas que les Anglais avaient mis au point les chemins de fer Helvétiques ... parce que pour utiliser une fréquence de 16,6666... Hz, il faut vraiment avoir été élevé avec le système impérial ;-)
http://en.wikipedia.org/wiki/Imperial_unit(...)
Quelqu'un peut-il éclairer ma lanterne sur la raison de cette valeur ?
Je sais que dans les avions le courant est en 400Hz pour réduire la taille et le poids des transformateurs, mais pour le train ca n'a sans doute rien à voir.
[^] # Re: En parlant de sources, "faille" GPL
Posté par Jimmy . En réponse au journal Une Freebox Media Player ?. Évalué à 3.
Free fait sans doute des modifications sur les logiciels libres qui tournent sur la Freebox (architecture MIPS il me semble), et j'ignore si ils envoient des patches aux développeurs quand ils trouvent un bug.
La GPL dit que l'utilisateur du logiciel libre doit avoir accès aux mêmes libertés que celui qui le lui fournit.
La question est sur la définition d'"utilisateur". Soit c'est Free, en tant que propriétaire de la Freebox et opérateur du transfert d'informations, soit c'est le client final en tant que destinataire des services offerts par les logiciels libres.
Est-on utilisateur de VLC quand on branche une TV sur une Freebox ?
Est-on utilisateur de iptables quand on choisit les règles du routeur sur le site de Free ?
Ou est-on juste "utilisateur^Wclient de l'utilisateur" ?
[^] # Re: Plutôt du FTP
Posté par Jimmy . En réponse au journal Une Freebox Media Player ?. Évalué à 3.
Ben si, il y a une péritel. Donc entrée/sortie
La norme Péritel supporte effectivement les signaux (RGB, composite et son) dans les 2 sens, mais qu'est-ce qui nous prouve que les entrées sont bien connectées dans la Freebox ? Pour en savoir plus il faudrait que je l'ouvre ...
Cette option de "passerelle multimédia" est assez intéressante, ca peut remplacer lirc + sortie TV [ composite :-( ] + son numérique jusqu'à la chaîne ... ou encore concurrencer les lecteurs DVD/DivX/MP3 de salon. En Wifi ca doit être assez magique.
Par contre, si ca c'est possible, je suis sûr que l'inverse aussi (et ca me serait plus utile puisque je n'ai pas de TV) : envoyer le flux TV en numérique vers le PC, pour affichage sur le moniteur. Mais il y a sans doute des pb de droits/redevance ...
En tout cas, si les interfaces de programmation sont dispo, il va sûrement y avoir plein de nouvelles idées à suivre ;-)
[^] # Re: 1ère impression...
Posté par Jimmy . En réponse au journal Brevets, une autre conception. Évalué à 3.
20 ans, c'est relativement logique pour une industrie lourde. C'est un peu court pour les industries pharmaceutiques (encore que, pour les malades c'est bien trop long ...). Et c'est une éternité en électronique et en informatique (rappel de la loi de Moore : x2 tous les 18 mois).
Je vais donc faire une proposition d'artilleur (ou de débianeux) : le brevet doit être valide un certain temps. Et ce temps serait variable selon les cas, selon les domaines, selon l'âge du Capitaine. Je le définirais bien comme "le temps nécessaire pour rembourser l'investissement" des recherches ayant abouti à l'invention. On considère alors que la société ne gagne de l'argent que sur les services associés à l'invention, et qu'une fois la concurrence rétablie elle part avec plus d'expérience et la confiance des clients. C'est déjà une bonne récompense pour l'effort de recherche.
La durée en question serait de qq 10 années pour les procédés mécaniques ou chimiques, qq années ou qq mois pour "les inventions assistées par ordinateur", et qq heures ou qq minutes pour les algorithmes, les idées, les poèmes ...
Par contre, comment juger de manière fiable, impartiale et efficace de cette durée de validité ? Et surtout, comment la faire respecter ?
Pfff, je n'en sais rien alors je vais me coucher.
[^] # Re: Autres solutions
Posté par Jimmy . En réponse au message Comment effectué une rotation de bit sur un Byte ?. Évalué à 3.
- si c'est la rapidité, alors il vaut mieux faire une LUT de 256 valeurs, c'est encore ce qui s'exécutera le plus vite. Par contre ca consomme un peu plus de mémoire (ca peut avoir son importance sur un petit CPU embarqué).
- si c'est la simplicité, et la taille de code (en mémoire) qui est recherchée, la méthode par décalage est très bien.
- certains CPU ont des instructions assembleur SWAP concues pour ca. Par contre, adieu la portabilité de ton code.
- si on a une vraie rotation de bits (pas juste un décalage avec perte du bit qui dépasse, mais généralement ca va nous ramener aussi à de l'assembleur) on peut faire ce genre de choses :
#define reverse_byte (byte) \
(((byte<<1)&0x11) \
| ((byte<<3)&0x22) \
| ((byte>>3)&0x44) \
| ((byte>>1)&0x88))
Si on décompose, ca fait :
000E 000A
H000 D000
00F0 00B0
0G00 0C00
-----------------
HGFE DCBA
Avantages : aucun test, aucune boucle, et on traite 2 bits à chaque fois.
Inconvénients : les constantes (mais sur un RISC elles sont mises avec l'instruction), la rotation qui n'est pas équivalente au décalage en C
Plus d'infos ici :
http://www.sxlist.com/techref/microchip/math/bit/revbits.htm(...)
[^] # Re: wine ? vmware ? qemu ?
Posté par Jimmy . En réponse au message logiciels windows à partir de linux ?. Évalué à 2.
Bon, maintenant c'est un peu différent, noyau NT toussa, mais je suis sûr qu'il reste une bonne partie des lignes de code du DOS d'origine dans NT 5.1 (aka XP). Qqun a les sources pour vérifier ?
[^] # Re: Sauvegarde
Posté par Jimmy . En réponse au journal L'inévitable est arrivé. Évalué à 3.
Je n'en ai jamais entendu parler, mais est-ce qu'il serait possible de faire une sorte de RAID à travers le réseau, de manière à sauvegarder une (petite) partie du disque de chaque machine sur toutes les autres ? Les tailles de disques sont très généreuses aujourd'hui, et on va avoir du mal à remplir des centaines de Go avec des mails, des tableaux de compta, des plannings et des devis ... On pourrait imaginer une petite partition sur chaque poste client, qui reçoit la garde d'un lot de données des autres postes clients et du serveur.
Finalement, ca ressemble à certains réseaux P2P où chacun ignore ce qui est stocké sur son disque (là c'est pour pouvoir dire "j'y suis pour rien M'sieur l'Juge"), par conséquent ca ne devrait pas poser trop de pb techniques. De plus, sur un réseau local la bande passante devrait être plutôt bonne.
Evidemment, cela ne répond qu'aux pb de type "un seul disque dur cassé", si jamais le local brûle il faut de toute façon avoir une autre sauvegarde en lieu sûr.
[^] # Re: Debian is still alive !
Posté par Jimmy . En réponse au journal Le futur de Debian. Évalué à 4.
D'abord, quelle partie de la distrib' certifiée pour le produit en question : le minimum-sans-X, l'install desktop par défaut (avec aucun daemon lancé), les 14 CD de sources au complet ? Si il y a plusieurs versions officielles de noyau dans cette release ?
Qu'est-ce qui garantit qu'une mise à jour de sécurité ou l'installation d'un autre paquet qui ne faisait pas partie de l'install certifiée ne va pas tout casser ? Et qu'est-ce qui fait croire qu'il peut y avoir un tel risque ? Quand on liste les prérequis sous Windows, on ne dit pas "nécessite Office 2003", ou "incompatible avec Quake III", on ne parle que de l'OS, de la mémoire et du disque dur ! Le reste, c'est la hotline qui se débrouille.
Je pense qu'il serait bcp plus pertinent de lister précisément les dépendances importantes. Je suis sûr qu'il n'y en a pas tant que ca, si ils veulent garder des secrets de fabrication ils incluent de toute façon des libs statiques. Généralement, ca va être des versions minimum de noyau, de libc, de toolkit graphique, et de deux ou trois outils spécifiques. Les outils de base (shell, API réseau, langages interprétés ...) sont très stables et ne posent pas de pb de compatibilité ascendante.
Par exemple, une appli proprio peut réclamer : "noyau 2.6.5 ou suivant (avec modules réseau et RAID activés), libc6 version x.y.z ou +, gtk X.Y mais surtout pas X.Z, perl 3 ou +, incompatibilité avec le paquet trucmuche de la version 0.0.8 à la version 0.1.4 ...
Au fait, les distribs Fedora >2, Mandake 10.*, debian sarge et LFS 2.0 ont les paquets correspondant à ces critères." On me souffle dans l'oreillette que apt-get, urpmi, yum et yast sauraient même gérer les dépendances ...
Ce ne serait pas beaucoup plus difficile à tester pour l'éditeur, et au moins on sait vraiment de quoi on parle. On garde ainsi le choix de la distrib selon sa propre préférence (voire des choix officiels de l'entreprise), on n'est pas liés à un éditeur d'OS (ce qui est un des arguments forts des logiciels libres, non ? OK, si c'est pour une appli proprio c'est déjà raté), et surtout on garde la possibilité d'évoluer !
Ou alors j'ai raté un épisode ?
[*] Je pense surtout aux logiciels de CAO, traditionnellement UNIX et progressivement portés sous Linux ces temps-ci.
[^] # Re: Bong sang ...
Posté par Jimmy . En réponse au journal Vive GNU/linux & Airbus A380. Évalué à 2.
Y'a un trackball à côté de la manette des gaz.
Et je vous assure qu'il n'y a malheureusement pas un seul pingouin dans les systèmes de pilotage : pour cela il faudrait passer une terrible certification (norme DO178B par exemple) dont le coût est hors de portée des développeurs de logiciels libres ...
(à vrai dire, il faut même commencer par certifier le compilateur !)
[^] # Re: Dans le même esprit....
Posté par Jimmy . En réponse au journal Vive GNU/linux & Airbus A380. Évalué à 3.
Il n'y a bien qu'un digit d'écart, car l'un s'appelle en vrai Windows NT 5.0, et l'autre est bel et bien Windows NT 5.1.
C'est d'ailleurs rigolo quand on les appelle comme ca, et que le windozien de base rétorque "mais non, tu vois bien que c'est XP", et qu'un petit coup de demarrer->paramètres->système lui cloue le bec.
[^] # Re: VT100
Posté par Jimmy . En réponse au journal La liberté .... belle utopie. Évalué à 2.
http://aa-project.sourceforge.net/index.html(...)
[^] # Re: ouais....
Posté par Jimmy . En réponse au journal Monad, le shell selon Microsoft (MSH). Évalué à 3.
http://fr.wikipedia.org/wiki/Hacker(...)
[^] # Re: 64 ou 32bits ?
Posté par Jimmy . En réponse à la dépêche Apple abandonne IBM pour Intel. Évalué à 4.
Windows ne tourne pas _que_ sur x86.
Cf. le kit de développement de la Xbox2 qui est un bi-G5.
On se croirait dans une cour de récré : il est bô ton jouet, on échange ?
Moralité : quand on a les sources, on fait ce qu'on veut, sur le hardware qu'on veut.
[^] # Re: Compilateurs à disposition
Posté par Jimmy . En réponse au journal Apple abandonne IBM pour Intel. Évalué à 2.
Fortran reste le langage de référence pour faire du code de calcul optimisé. Dans mon travail les temps de calculs se comptent régulièrement en semaines...
Ben c'est ptêt pour ca ...
< /mode >
En vrai, je ne sais absolument pas ce que le Fortran a de plus que les autres langages pour le calcul scientifique, je sais juste que c'est le plus vieux langage "de haut niveau" (c'est à dire pas assembleur), et qu'à ce titre c'est le seul connu de certains directeurs fossilisés. J'espère que la réciproque n'est pas vraie.
[^] # Re: format binaire "universel"
Posté par Jimmy . En réponse au journal Mac sur puces Intel, ça marche déjà. Évalué à 2.
D'ailleurs, cette précedente transition avait été franchement bien menée, notamment parce que l'émulation du 68k par le PPC était très efficace (plus que le 68k natif il me semble). De plus, je crois que la compatibilité 68k n'a été cassée que avec MacOS X (ou peut-être le 9, qui n'était pas censé exister initialement).
Concernant le pb d'endianness (qui ne s'était pas posé à l'époque, le 68k est big-endian aussi), comment vous faites pour faire des champs de bits portables en C ? De mémoire [inversion possible] on peut faire comme ca mais c'est pas top :
#ifdef little_endian typedef struct{ int champ1: 8; int champ2: 2; int reserved: 22; }toto #else /* big_endian*/ typedef struct{ int reserved: 22; int champ2: 2; int champ1: 8; }toto #endif[^] # Re: Le lien avec, c'est mieux ;-)
Posté par Jimmy . En réponse au journal Cartes de référence. Évalué à 4.
http://www.digilife.be/quickreferences/quickrefs.htm(...)
http://refcards.com/refcards/index.html(...)
Juste deux petites remarques :
- Tu gagnerais du temps en améliorant ce qui existe déjà. Je n'ai pas fait gaffe aux détails de licences, certaines sont sous GFDL, mais à priori dans tous les cas c'est fait pour être diffusé et amélioré.
- en recto-verso c'est plus pratique, comme il y a plus de place on peut écrire plus gros ou mettre encore plus de choses.
Bon, j'arrête de critiquer, elles sont très bien tes refcards, c'est du bon boulot ! Je crois que je vais en laisser qqunes dans la photocopieuse lundi, pour faire de la pub aux licences CC ;-)
[^] # Re: Décidément
Posté par Jimmy . En réponse à la dépêche Nouveau rebondissement dans l'affaire du pilote PWC. Évalué à 2.
Justement, c'est la question que je pose juste après ...
ceux qui ne passent pas au libre, on s'en fout, ils ont deja achete leur cam pour windows
La question qu'on peut se poser, c'est la raison qu'ont ceux qui restent avec un système onéreux, buggé et liberticide alors que l'alternative existe. Il y a entre autre le manque d'information/pub, la réticence au changement, les formats fermés et effectivement le manque de support pour certains périphériques.
Je considère qu'on ne s'en fout absolument pas, et qu'il y a sans doute des gens qui n'utilisent pas Linux juste parceque leur webcam ne marche pas avec ! Tu essayes de promouvoir les logiciels libres, ou de faire fuir les newbies ?
trop peu nombreux, sinon philips et ses potes ne cracheraient pas sur leur argent.
[Ca me rappelle la devise du Virus Informatique. 50G mouches ne peuvent pas _toutes_ avoir tort !]
Là aussi, qu'est-ce qui prouve que leur estimation du marché est juste ? Le nombre d'utilisateurs de Linux est bien moins facile à mesurer que les profits de M$ ! Et ces paramètres sont liés : si les fabricants étaient plus coopératifs, ca encouragerait les gens à utiliser les logiciels libres, et réciproquement.
[^] # Re: c'est le terme professionnel utilisé
Posté par Jimmy . En réponse à la dépêche Concours : réalisation d'un kakémono pour Léa. Évalué à 6.
En français, et avec un peu d'imagination, ca pourrait se traduire par étandard, non ?
[^] # Re: Décidément
Posté par Jimmy . En réponse à la dépêche Nouveau rebondissement dans l'affaire du pilote PWC. Évalué à 9.
Le problème, c'est pourquoi attendre un "seuil critique" ?
Publier des specs n'est pas un travail énorme (comparé au développement lui-même, et dans la mesure où ces specs existent forcément en interne) et effectivement la communauté fera le boulot. Elle le fera de toute façon si elle en a vraiment besoin, mais la grosse différence c'est l'image de marque du constructeur (surtout si "il renvoie chier les linuxiens"). Je pense que les constructeurs sous-estiment la communication dans la communauté, une bonne ou une mauvaise pub circule très vite (à la vitesse du troll au galop, en fait).
En ce qui concerne les concurrents qui auraient ainsi accès au design, ne vous en faites pas, ils l'ont déjà : eux aussi ils font du reverse-engineering, et pas avec des moyens amateurs.
Quant à savoir si c'est rentable, encore faudrait-il avoir des chiffes fiables concernant le nombre d'utilisateurs de GNU/Linux (et BSD, Hurd, Minix ...) pour parler de parts de marché, et prendre en compte tous ceux qui ne passent pas au Libre parce que leur périphérique chéri n'est pas (bien) supporté ...
Finalement, je ne sais pas si "malin" est le bon adjectif ...
[^] # Re: patch externe ?
Posté par Jimmy . En réponse à la dépêche Nouveau rebondissement dans l'affaire du pilote PWC. Évalué à 3.
On peut recopier l'effet d'un programme
Il s'agit donc de copier l'algorithme, et d'en faire une nouvelle implémentation. C'est l'implémentation qui est protégée par le droit d'auteur, pas l'algo qui lui n'appartient à personne (formule mathématique, patrimoine de l'humanité, toussa).
Enfin, tant qu'il n'y a pas de brevets sur les logiciels. :-/
Un reverse-engineering par analyse des entrées/sorties de la boîte noire (façon Tridge pour Samba) est donc acceptable.
Mais on ne peut pas plagier un programme
Là où c'est difficile, c'est de faire la distinction entre une implémentation "sincère" de l'algo, qui ressemble à l'implémentation protégée juste parce qu'il était logique de faire comme ca (structures de données classiques, nommage explicite, ...), et un repompage intégral avec "obfuscation" et mauvaise foi.
Un reverse-engineering par décompilation permet de faire l'un ou l'autre, selon l'effort et l'intelligence qu'on met dans la compréhension (abstraction) et la re-création (implémentation) du programme.
Pour reprendre l'exemple littéraire, si j'invente un super-pipotron avec analyse sémantique et générateur de synonymes, et que j'y passe un roman célèbre, ce sera toujours la même histoire, juste avec des mots différents. C'est clairement un plagiat, je n'ai pas crée de contenu culturel. (quoique, un bô pipotron comme ca, c'est pas simple à faire et ca intéresserait sûrement les hommes politiques ...)
Maintenant, si je mixe plusieurs romans sur le même thème, ou que je réécris des passages pour brouiller les pistes, que j'influe sur le style ou le vocabulaire utilisé par le programme, à partir de quel moment cela devient-il une oeuvre originale ? Comment faire la différence avec une simple "inspiration", une référence culturelle ? Si je réécris un San-Antonio avec le vocabulaire de Molière (ou l'inverse, c'est vous qui voyez) est-ce encore la même oeuvre?
L'exemple marche aussi pour la musique, avec l'échantillonnage (sample), les remixes et autres reprises (dont certaines sont créditées en tant que thème "traditionnel" pour ne pas reverser de droits).
Finalement, c'est encore l'autorisation (ou non) des travaux dérivés par les licences Creative Commons qui est la plus claire ...
[^] # Re: Ca existe pas déjà?
Posté par Jimmy . En réponse au journal Idée à la con. Évalué à 2.
On ne pourrait pas faire le même genre de choses avec un simple joystick, un modèle ambidextre pour l'utiliser avec la main qui ne tient pas la souris, et qui gère la rotation du manche ? Ils se branchent tous en USB maintenant, on devrait pouvoir gérer sans trop de mal plusieurs périphériques d'entrée.
Et pourquoi pas aussi des pédales de volant-pour-jeu-de-bagnole, toujours en USB, histoire de se muscler un peu les chevilles et de pouvoir enfin faire des raccourcis clavier sous Emacs ;-)
[^] # Re: comment rendre inutilisable un format ouvert...
Posté par Jimmy . En réponse au journal Microsoft brevete la sérialisation vers un fichier XML !. Évalué à 2.
http://linuxfr.org/comments/424329.html#424329(...)
Les "screenchoutes" de Gnome et KDE sont là pour illustrer l'état de l'art, M$ brevetant un truc un peu différent (en gros, la vue miniature de tous les bureaux, mais maximisée sur tout l'écran).
Je ne vois quand même pas où est la nouveauté là-dedans ...
[^] # Re: ptit detail
Posté par Jimmy . En réponse au journal Du DRM dans les Pentiums. Évalué à 2.
Bien plus que ca à mon avis (mais ce n'est pas toujours marqué en grand sur la puce ! ). Il suffit de voir que Jiri Gaisler arrive à en vivre ...
J'ai fait une éval d'une puce qui contenait plusieurs LEON, et c'est un bon p'tit proc. Je dis "p'tit", car comme il est très configurable, le fabricant avait choisi une implémentation minimale : pas de FPU, pas de MMU, pas de division, pas de PCI ni Ethernet ... et pour cette application ca se comprend.
Avec toutes ces options, on fait tourner Linux, eCOS ou Solaris sur ce CPU compatible SPARC sans pb.
On peut aussi l'impanter sur un FPGA (circuit logique programmable), avec l'inconvénient d'une fréquence moindre, mais l'avantage d'être reconfigurable et de pouvoir développer des coprocesseurs ...
Juste un petit bémol : le code VHDL du CPU est libre, les outils de développement "de base" (compilo, débugger ...) sont libres, mais les outils "haut niveau", notamment le simulateur TSIM, sont propriétaires et onéreux (cf. deuxième phrase de ce post). Quant à la version du CPU durcie aux radiations, je pense que ca ne concerne pas bcp de monde ici ;-)
+ d'infos sur http://www.gaisler.com(...)