rewind a écrit 3442 commentaires

cp / mv / rm dans Konsole

"C'est la raison qui pousse au quotidien à utiliser kde"

Non, c'est ta raison qui te pousse au quotidien à utiliser kde. Personnellement, je n'utilise quasiment jamais Konqueror (sauf en tant que client ftp et aussi pour vérifier que mes pages web passent bien avec Konqueror). Et pourtant, j'utilise KDE quotidiennement et j'aime beaucoup KDE.

Sinon, pour l'intégration de Dolphin dans Konqueror, il suffit de lire un peu :
http://techbase.kde.org/Schedules/KDE4/4.0_Release_Beta_Goal(...)

"Il est important de comprendre que si vous aimez le logiciel libre, ce n'est pas nécessairement pour les mêmes raisons que votre voisin. L'une comme l'autre sont valables du point de vue de chacun. " -- ploum

"- La gestion des codecs propriétaires natif MP3 des lecteurs Amarok et Totem, via un acquis d'une licence globale de Novell envers Fluendo."

C'est moi ou alors il y a vraiment un souci par rapport à la politique de Novell qui veut enfermer ses utilisateurs avec des contrats exclusifs genre MS ou Fluendo ?

Je doute que ces codecs soient librement redistribuable, mais je pose quand même naïvement la question.

Creuse profond pour bien l'enterrer :P

Ben j'ai lu quelque part parmi ces commentaires que le compilateur faisait des optimisations pour garder tout dans une seule ligne de cache. Très bien. Maintenant, croire qu'on peut faire ça de manière générique pour toutes les architectures et tous les algorithmes, c'est être sérieusement optimiste (ou illuminé, c'est selon).

Pour avoir déjà vu des gens qui ont ce genre de problématique quotidiennement dans l'embarqué, l'optimisation des structures de données et de leur emplacement en mémoire ainsi que de l'organisation du code pour provoquer le moins de défaut de cache possible, c'est quasi-spécifique à chaque couple (algo-archi) et ça demande énormément de temps. Et ça demande de pouvoir maitriser toute la gestion de la mémoire de A à Z.

Je vais te filer un poly de logique d'une centaine de pages dans laquelle il n'y a pas la moindre petite ligne de code ou même une seule allusion à la programmation et on en reparle après...

Du bytecode pour l'embarqué, c'est la meilleur de l'année.

Ouais, un peu comme un langage qui gère lui même la mémoire pour l'embarqué, j'en ris encore...

Dans la recherche, il parait qu'on doit pouvoir refaire les expérimentations pour valider les résultats. Or sur la page benchmark, il y a de jolis résultats mais rien qui permettent à M. Lambda (moi) de refaire ces expérimentations. Il manque le code du décodeur MPEG-2 ! Tous les autres détails genre la machine ou les options de compilation ne servent à rien sans ce code.

Serait-il possible de l'avoir ? Y a-t-il d'autres benchmarks disponibles ?

Ce document a l'air très attaché à son école d'origine. Je pense que ça peut représenter un problème pour un éventuel contributeur qui souhaiterait ajouter une partie intéressante pour son contexte ou enlever certaines parties qui lui paraissent inutiles. Par exemple, il y a beaucoup de choses concernant OpenVMS, on sent tout de suite que l'école utilise ce genre de machine (et que ça a sa place), mais pour une initiation plus généraliste, doit-on réellement connaître toutes les variantes de tous les OS du marché ? (D'ailleurs, parler de Windows-NT dans un document intitulé "Initiation à Unix", je trouve ça osé mais encore une fois, c'est certainement une question de contexte)

Autre remarque, j'ai ouvert le pdf et j'ai commencé à le lire. Déjà, feuilleter 23 pages avant d'arriver au contenu, ça fait sans doute trop. Il vaudrait mieux déplacer toutes les tables des matières et listes à la fin, y compris la longue liste de marques déposées en préface. Ensuite, juste sur la première page, on se demande vraiment si c'est un document d'initiation quand on parle de "process", d'interpréteur de commande (qu'est-ce qu'une commande ? qu'est-ce qu'un intépréteur ?). Ça peut rebuter de vrais débutant de commencer. Ou alors il faut changer le titre. Sur la deuxième page, KDE n'est pas un projet de la FSF (GNOME en revanche l'est bien).

Je m'arrête là, parce que d'une part, je ne suis pas allé plus loin et d'autre part, on va me répondre "participe" et je n'ai pas le temps de participer. Mais voilà mon premier ressenti quand j'ai ouvert ce document.

Pour tous les amateurs de Debian, il y a bien évidemment Apt dans le Vaucluse :)

http://fr.wikipedia.org/wiki/Apt_%28Vaucluse%29

Ho, sainul ! Y'a même pas Poil [1] (Tous à Poil !) mais il y a Bèze [2] !

[1] http://fr.wikipedia.org/wiki/Poil_%28Ni%C3%A8vre%29
[2] http://fr.wikipedia.org/wiki/B%C3%A8ze D'ailleurs, la page wikipedia de Bèze est très bien documentée, sans doute un fan de Bèze.

il ne s'agit pas d'un outil de gestion de conférence/jounal (dont il manque pourtant un bon représentant libre)

Raté ! http://myreview.lri.fr/
Et en GPL ma petite dame, oui oui !

Tant que j'y suis, pour le C++, il y a le polycopié de Henri Garreta :
http://www.dil.univ-mrs.fr/~garreta/Polys/PolyCpp.pdf

Idem que l'autre, hyper bien fait, un must quand on veut apprendre le C++ facilement.

Je conseille toujours l'Introduction à l'ANSI C de Bernard Cassagne pour tout ceux qui veulent débuter le C. C'est bien fait, didactique et pas trop chiant à lire.

http://www-clips.imag.fr/commun/bernard.cassagne/Introductio(...)

Est-il possible ou sera-t-il possible de récupérer des données sur des vieux CDROM abimés par l'usage et le temps ? Parce que j'en ai quelques uns qui sont devenus à peine lisible et j'ai parfois du mal avec certains fichiers.

"ou qui passe par la connerie de l'utilisateur (jesuischaude.exe )"

expérience toussa ? :P

J'aurais plutôt dit du foutage de gueule mais bon...

Ou pas.

Comme je l'ai dit dans les commentaires du journal, il faut arrêter de dire que Jabber va tout remplacer : mail, IRC, etc. IRC est encore là parce qu'il n'y a aucune alternative crédible sur plein de points : efficacité au niveau de la bande passante, scalabilité, échanges de fichiers. IRC a l'énorme avantage d'être simple (comparé à Jabber) et d'avoir diverses implémentations sur diverses plateformes. Pour Jabber, il y a... des spécifications et rien d'autres.

Sur le papier, Jabber est certainement mieux qu'IRC, dans la réalité, il en est tout autrement et IRC surpasse largement Jabber sur son créneau : la conversation en salon. Que Jabber soit déjà un bon protocole de messagerie instantané (avec des implémentations client et serveur crédible face à MSN Messenger) et ensuite, il pourra prétendre s'étendre à un protocole de conversation en salon ou de discussion avec une cafetière s'il le veut.

Jabber et IRC n'ont rien à voir selon moi. IRC, c'est des canaux de discussions par défaut, Jabber c'est de la communication one to one. Après, chacun des deux permet de faire l'autre mais je dois avouer que je n'ai jamais accroché aux salons Jabber. Peut-être parce que les clients Jabber sont des clients de messagerie instantanée qui ne sont pas adaptés aux discussions en salon.

IRC est loin d'être un protocole trop vieux. Il est encore très utilisé pour une raison : il comble un besoin que ne comble pas d'autres protocoles comme Jabber ou MSN. Surtout si des gens tente de faire évoluer IRC comme avec cette initiative.

Alors crier qu'il faut utiliser Jabber, moi je veux bien, mais je suis loin de trouver le confort et le plaisir d'IRC dans un salon Jabber. Je ne veux pas cracher sur Jabber parce que je l'utilise quotidiennement, mais il faut arrêter de dire que Jabber va remplacer tout : mail, IRC, toussa. Si Jabber pouvait déjà faire de la messagerie instantanée comme MSN, je serai déjà très heureux.

En gros, c'est une réimplémentation de primitives haut niveau (for, while, etc) et de containers de la STL. Mais il y a des contraintes, par exemple le parallel_for doit s'éxécuter sur des tâches indépendantes.

C'est pas très nouveau comme concept, il y a notamment STAPL qui existe depuis pas mal de temps [1]. Cette présentation [2] fait un comparatif des fonctionnalités d'autres librairies/langages du même genre.

Je n'ai pas encore jeté un oeil sur le code mais il semblerait que ce soit fait à base de vol de travail comme le suggère [3]. Mais ça m'intéresse de voir comment ils font ça de manière efficace.

[1] http://parasol.tamu.edu/groups/rwergergroup/research/stapl/
[2] http://www.cs.unm.edu/~fastos/06meeting/FASTOS-STAPL_2006.pd(...)
[3] http://assets.devx.com/goparallel/19703.png

On connaît Pi bien mieux qu'avec des encadrements. C'est le plus petit nombre strictement positif tel que cos(Pi/2) = 0 et ça le définit entièrement et exactement. Ce n'est pas comme une constante de physique qu'on va approcher petit à petit mais qu'on ne connaîtra jamais de manière exacte ; on connaît Pi de manière très exacte.

C'est pas des murs en béton mais un mur mou (soft wall en anglais) [1] et d'ailleurs, Indianapolis a été le premier ovale à en bénéficier.

Sinon, pour ceux qui préfèrent les courses sans pingouin sur les voitures (mais avec l'Armée Américaine, M&Ms, Dupont et autre Cingular), il y a le Coca-Cola 600, la plus longue course de l'année en NASCAR Nextel Cup (600 miles pour ceux qui n'auraient pas suivi).

[1] http://en.wikipedia.org/wiki/Soft_wall

> A la base les droits d'auteurs sont là pour garantir l'indépendance financière des auteurs.

Archi-faux. À la base, les droits d'auteur sont là pour garantir à l'auteur qu'on ne pourra pas lui voler son oeuvre. La question de la rémunération des auteurs a toujours été une question complètement à part et ne concerne qu'une très faible proportion des auteurs.

Si je ne me trompe pas, c'est une émission de radio qui passe sur les ondes locales, et donc, elle est susceptible d'être entendu par pas mal de gens, non ? Rien n'empêche un peu de pédagogie, si on n'arrive à l'expliquer simplement entre nous, ça sera plus facile de l'expliquer à quelqu'un d'autre qui n'y connaît rien.

Alors, oui, certes, je me suis moqué gratuitement là, je m'en excuse, mais l'intention n'était pas méchante, Je pense que tu l'as compris. Je trouve très bien de faire ce genre de chose, et je vous souhaite de continuer comme ça.