[ Précédent :: 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 :: Suivant ]
Re: l'Almanach Vermot du chat de Schroedinger
Dans le même style, une petite devinette:
C'est Exponentielle et Logarithme qui vont au restaurant. Qui paye ?
Solution: Exponentielle, car le logarithme népérien.
Bon j'assume et je -->[]
[ Répondre ]
Re: Sondage : la compilation du noyau / des modules
Et quid de la SID ?
Bah spareil:
leeloo $ gcc --version
gcc (GCC) 3.3.1 20030722 (Debian prerelease)
Oui un gcc 3.3.1...
Et qui ose dire que la Debian utilise des antiquités en guise de logiciels ?
Bon je ->[]
[ Répondre ]
Re: Transgaming, Gentoo Inc et le code.
>Malheureusement, la puissance de portage rendait WineX trop facile à installer. Pas vraiment besoin de portage pour installer winex facilement. Faudrait aussi interdire de publier ce genre de chose:
./configure \
--enable-opengl \
--enable-pthreads \
--prefix=/opt/winex
make clean all
su -c "make install"
echo "PATH=\$PATH:/opt/winex/bin" >> $HOME/.bashrc
echo "LD_LIBRARY_PATH=\$LD_LIBRARY_PATH:/opt/winex/lib" >> $HOME/.bashrc
Sinon t'as bien raison de dire qu'ils cherchent juste à se faire aider par des développeurs, car j'ai pas vu de fichier INSTALL présentant la config de winex après installation.
[ Répondre ]
Re: La tele
>Je crois que la fréquence de rafraîchissement est de 50Hz (la même que pour le 220V). Ou alors, si l'image est entrelacée, ça nous donne du 25Hz (je ne sais plus si c'est entrelacé ou pas en fait).
La télé en France c'est:
- rafraichissement de 50 hertz.
- une trame par rafraichissement (soit les lignes paires, soit les lignes impaires).
- 2 trames pour une image complète, soit 25 images/s.
Voilà, avec çà t'as plus de doutes a avoir...
[ Répondre ]
Re: bureau virtuel et second écran...
La solution serait plutot de démarrer deux serveurs X11, un pour l'écran du portable, l'autre pour la sortie TV.
Doit y avoir mieux quand meme comme solution.
[ Répondre ]
Re: Combien de personnes liront ce journal privé?
COPITEUR !
[ Répondre ]
Re: Changements du formulaire des journaux
Bug, tous les journaux publiant des URLs ne génèrent plus de balises <a href="ton url">le lien</a>
[ Répondre ]
Re: Gentoo 1.4 sortira pour la LinuxExpo 2003
C'est pas la 1.4 qui devait sortir en septembre 2002 ? Je m'en souviens à l'époque je me disais "attends la 1.4 et juge la gentoo sur cette version aboutie". Que s'est il passé pour que le développement de la distrib eut été bloqué aussi longtemps ?
[ Répondre ]
Re: teelpmeT snad gub ed elôrD
LS0vLS0tLy4uLy0tLi4tLSAuLS0tLy4gLi0tLi8uLS4vLi8uLi0uLy4vLi0uLy4gLi0uLi8uIC0t
Ly0tLS8uLS4vLi4uLy4gLS8uLS4vLi0vLS4vLi4uLy4uLS4vLS0tLy4tLi8tLS8uIC4vLS4gLS4u
Li8uLS8uLi4vLi8tLi4uLi8uLi4uLS8uLS4tLi0=
[ Répondre ]
Re: Hashzip
>For every 256 bytes of input, 30 bytes of output result, guaranteed. The big
>challenge that lies ahead is to 'verify' this works for all possibilities of
>bits (2^256 verifications).
Bah c'est simple, cette boite vient d'inventer la compression "à l'infini". Voici la recette:
- Découper un fichier en blocs de 256 octets.
- Passer le tout à la moulinette magique de compression i2bp^WFree Daemon Consulting.
- Egouter ensemble tous les résultats de 30 octets. Réserver au frais.
- Recommencer à la première étape jusqu'à obtention d'un bouillon compressé de 30 octets au total.
Pourvu que s'dure !
[ Répondre ]
Re: Avis de la communauté sur les différentes distributions
Petite correction, depuis la 8.0 les mdk possèdent un outil "équivalent" à apt-get:
Sous mdk: urpmi le_soft_que_tu_veux
Sous debian: apt-get install le_soft_que_tu_veux
Voila pour quoi je comprenais pas pourquoi mdk et rh (qui elle ne possede pas de urpmi de base, amoins d'installer apt4rpm dans un deuxieme temps) avaient trois *.
Bon maintenant si on parle de frontend à apt-get:
- aptitude (frontend console, mais fichtrement efficace, permet de vraiment bien manager ses packages avec quelques touches)
- synaptic (frontend GTK, pas testé donc chuteux... :-)
Puis je pense que la maintenabilité des distributions est importante aussi. Surtout si le public visé est un public professionnel... on a rarerement envie de se saboter une machine de prod pour upgrader la distribution. Ca devrait être un critère à prendre en compte.
Pour le système de notation, les étoiles sont trop restrictives et n'apportent pas assez d'information.
Pourquoi ne pas adapter la notation en fonction de ce que cela représente: Exemple:
Installation:
- peu de questions techniques
- configuration du matériel automatique
- ...
Certes ca complique un peu le systeme de notes, mais le lecteur y trouvera plus d'information. Mieux informé, un utilisateur ciblera mieux sa distrib.
Pour moi Debian Testing ou SID:
Installation:
- mode console
- questions pouvant être techniques.
- minimale (60MB) , c'est à l'utilisateur de rajouter par la suite les outils dont il veut se servir.
Installation des logiciels:
- Très simple en console avec apt-get, apt-cache. La gestion des dépendances est automatique.
- Ils existen des frontend: aptitude (console), synaptic (graphique)
Configuration:
- Les outils proposés sont souvent destinés à une administration à distance, et donc le plus souvent de petis utilitaires consoles.
Facilité d'utilisation:
- Une fois configurée, c'est votre GNU/Linux à vous... donc on s'y sent bien. La maintenabilité y joue aussi un grand role.
Stabilité:
- Les logiciels installés sont souvent très stable (certains diront même vieux). Mais ce choix est fait pour offrir un maximum de stabilité aux environnements de prod.
Dynamique:
- tout dépend de la version utilisée:
* SID: très dynamique (version de développement).
* Testing: dynamique mais pas trop (version qui deviendra Stable).
* Stable: Distribution gravée dans le marbre, gage de stabilité maximum.
Maintenabilité:
- Passer d'une version de distrib à une autre, upgrader tout son système peut se faire en une commande, et se fait très souvent sans aucun dommage notable sur la configuration de la machine.
Public visé:
- utilisateur plutot confirmé ou désireux de mettre les mains dans le camboui de temps à autre,
- ou ancien matériel,
- ou machine de prod,
- ou machine exotique (11 plateformes supportées).
[ Répondre ]
Re: Avis de la communauté sur les différentes distributions
Je pense qu'avant de mettre des étoiles, il serait bon de mieux connaitre les dites distributions (meme si tu avoue utiliser une MDK au quotidien et le reste n'étant que de rapides tests).
Car quand je vois:
Debian : ... Installation des logiciels : **
et toutes les autres distribs avoir trois étoiles... y compris windows qui ne possède pas de système de package proprement dit (les setup.exe certes c'est commun, mais ca ne prend pas soin de la cohérence du système)
Bah j'ai comme un petit doute.
Tout comme le manque d'outils graphiques sur la Red Hat me semble douteux pour la configuration puisqu'il y a plus de 3ans, y'avais linuxconf qui avait un frontend GTK et ncurses. Donc depuis ca a bien du progresser un chouilla.
[ Répondre ]
Re: Arch: un programme de gestion de version prometteur.
Mince j'ai oublié de citer celui là:
http://abridgegame.org/darcs/(...)
Par contre, j'y ai pas touché mais son approche (telle qu'elle est décrite sur le site) du problème du versionning semble proche de celle d'Arch... mais je peux pas en dire plus.
[ Répondre ]
Re: Cette news c'est une merde !
>les "features vraiment novatrices" par rapport à CVS sont avant la version 1.0 (atomicité, gestion des répertoires, versionning de branche, coût 0 des copies, meta-donnée). Tu confirmes j'espère ?
Non, pour moi ces features sont en grande partie que des corrections des erreurs de CVS. C'est pourquoi pour moi, les features que j'attend sont pour l'apres 1.0.
Ceci dit je le répète je ne crache pas sur Subversion mais Darcs et Arch me semblent bien plus prometteurs que Subversion.
[ Répondre ]
Re: Cette news c'est une merde !
> NON et NON et NON subversion ne fait pas du sur place.
Si tu crois que j'ai dis que Subversion etait moribond, c'est complètement faux, le développement de Subversion va bon train. Mais en terme de fonctionnalités, je suis désolé mais Subversion évolue TRES (trop?) lentement. Trop de choses sont reportées pour l'après 1.0.
> Excuse moi mon cher Edouard Gomez, mais tu es un con.
Ce jugement gratuit montre que je parle à un connaisseur en la matière.
>Si tu t'étais renseigné 2 secondes tu aurais vu que ce que tu apprécies sur arch, existe sur subversion :
>[liste de features...]
Je n'ai jamais affirmé que Subversion ne répond pas à certains problèmes de CVS, et cette liste de features est accessible sur le site de tigris, dont j'ai posté le lien pour que les lecteurs puissent aller chercher des informations complémentaires, y compris sur Subversion, le projet que je tente de diaboliser d'après tes dires... ah mais oui ! je ne suis qu'un con, c'est vrai, j'oubliais.
Maintenant, regardons plus en détail cette liste de features:
>commits atomiques
oui rien a redire, c'est présent depuis que je connais Subversion
>Subversion, le backend, est orienté base de données. Actuellement il utilise Berkeley DB mais après la version 1.0 d'autre base de donnée seront supporté (mysql/postgresql, etc).
Sur ce point, je dirais que sur le papier, ce point a l'air très intéressant, mais lorsque j'ai testé Subversion sur l'import d'un noyau Linux 2.4.19 en Octobre 2002, le backend BerkeleyDB massacrait les perfs de Subversion... l'import en _local_ sur un p4 1.5GHz et 512MB de RAM avait mis 40minutes... le premier checkout 20Minutes. Les commits eux étaient raisonnables et tournaient autour de 2/3 minutes le temps de traverser l'arbre complet des fichiers (qui est conséquent). Ce qui semble etre un avantage, ne l'est peut etre pas dans tous les cas. J'espère que Subversion a progressé dans ce domaine.
>Subversion consomme peut de réseau. Seul les diffs circulent et en compressé.
Cette innovation est bien mince mais certes bon point pour Subversion.
>Subversion dispose déjà de client graphique qui tourne sous Unix et Windows.
Oui en effet, tu fais bien de le signaler. Subversion possède plus d'outils périphériques. Pourquoi ? Car ca fait déjà quelques temps qu'on nous le présente comme LE successeur de CVS. Il attire donc plus l'attention des développeurs que Darcs ou Arch. Il est alors tout a fait compréhensible qu'on trouve ces outils plus user friendly...
>Subversion dispose déjà de client graphique qui tourne sous Unix et Windows.
Sur ce point je n'ai rien a redire, c'est une vrai force de Subversion.
>Le protocol réseau de Subversion est parfaitement standard puisque c'est webDav. Tout client Dav peut fouiller un dépôt Subversion. Pour le serveur, Apache est utilisé (+ module dav + module subversion). C'est une garanti d'efficacité et de sécurité. C'est donc très facilement qu'https est dispo..
Oui, tout à fait vrai, Subversion a su exploiter ce que WebDAV offre de base (opérations classiques sur fichier + versionning). Maintenant il faut aussi avouer que ce choix du "tout WebDAV" a énormément complexifié le backend. L'implémentation dav de subversion est loin, très loin d'être triviale.
>C'est "presque rien de plus que CVS" ? Subversion veut remplacer CVS mais au près des utilisateurs ! Ça ne veut pas dire que Subversion va recoder CVS ! Faut être con pour croire ça.
Je n'ai jamais avancé de tels propos. Inventes ce que bon te plais. j'ai juste dis que "Subversion se positionne comme LE successeur de CVS".
>> A dire vrai, des projets comme meta-cvs, se greffant sur CVS, font presque aussi bien que Subversion tout en étant bien moins compliqués.
>100 % pure troll.
1/ le terme "compliqué" se réfère à l'implémentation, non à l'outil vu par l'utilisateur.
2/ Relis la page de tigris, les features vraiment novatrices sont pour "l'après 1.0" qu'on attend si patiemment. Et toi même tu l'avoues.
>C'est news c'est de la MERDE.
D'abord on dit "_cette_ news c'est de la MERDE". Puis ensuite je remarque juste que ton commentaire n'est pas constructif... bref tu ne réhausses pas le niveau si pitoyable de ma news.
>PS : NRV.
T'es pas beau quand tu t'ennerves, reste calme, c'est juste un conseil de la part du "con".
[ Répondre ]
Re: Arch: un programme de gestion de version prometteur.
Faut-il comprendre que le cout varie en fonctions du nombre de revisions/patches ?
Non, le cout est constant.
En gros, Arch va juste créer un répertoire pour la nouvelle branche (si besoin est) et la seule chose qui distingue un tag d'une version normale c'est la présence d'un fichier CONTINUATION dans le répertoire du patchset.
[ Répondre ]
Re: Noyau : une nouvelle technologie d'ordonnencement
Breveter maintenant n'est plus possible, car l'invention a été révélée au public... bon maintenant rien ne l'empeche d'avoir été berveté avant ce post (pas envie de me palucher la liste des brevets pour vérifier ;-)
[ Répondre ]
Re: c ansi
pour avoir des entiers très longs, il me semble que c'est "long long" (8 octets) ou "quad" (pareil), mais c'est à vérifier.
La norme ANSI C (aka ISOC89) ne prévoit pas de types entiers de 64bit. Par contre il est vrai que la norme ISOC99 fixe un "long long" comme étant un type entier de 64bit.
Le terme "quad" m'évoque bien plus l'assembleur IA32 ou effectivement on y cotoie des "quad word" pour le MMX (instructions post/prefixées par "q" ou "p", movq, por, pand, pmul, padd pour indiquer que ca travaille sur les registres MMX 128bit).
[ Répondre ]
[ Précédent :: 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 :: Suivant ]



Re: RedHat porte plainte contre SCO.
Au delà tu tapage médiatique qu'on a pu faire pour les faire plier... on a eu droit à rien, et comme tu le signales si bien, Sigma a même sauvé les apparences en disant que c'était leur choix de publier les sources.
Donc pour faire cours:
- l'affaire Sigma vs XviD est fini depuis longtemps.
- XviD n'y a rien gagné et les auteurs encore moins.
- Sigma n'a jamais avoué clairement leur faute, et Sigma s'est bien foutu de la gueule du Libre à travers leur attitude.
A savoir qu'aux états unis, nous (auteurs d'XviD) aurions pu demander des dommages et intérets pour non respect de nos droits d'auteurs, mais n'ayant pas une thune à perdre dans des procès, et vu le flou juridique autour de la légalité même d'XviD[1], nous ne nous y sommes pas risqué... des fois que ca se retourne contre nous.
[1] le MPEGLA ne souhaite pas se prononcer sur la légalité de codecs distribués ss forme de sources. En effet, il est très difficile de juger si un source est un produit fini et donc soumi aux licenses MPEGLA, ou s'il s'agit d'une réécriture de l'implémentation de référence, auquel cas le MPEGLA ne pourrait demander des royalties.
[ Répondre ]