Mildred a écrit 2247 commentaires

J'ai des e-book, légalement achetés ou acquis, et ça marche très bien.

Par contre, c'est vrai qu'il faudrait voir des éditeurs importants se lancer dans l'e-book sans DRM pour pouvoir avoir accès à plus de quelques livres.

???

LLVM est fonctionnel.

Ce qui n'est peut être pas fonctionnel complètement, c'est LLVM-clang, surtout lorsqu'on considère le langage C++. Ce projet vise a créer un front-end pour les langages dérivés du C.

Mais LLVM en lui même est un framework complet de compilation, qui inclus des front-end (clang, gcc, ...) et des back-end (fichiers objets natifs, bytecode pour une machine virtuelle, code C, ...). Il y a un langage assembleur spécifique à LLVM et standardisé qui permet aux deux parties de communiquer.

Cette approche de la compilation par analyse de flot se retrouve aussi dans Lisaac ... un langage assez proche de Eiffel en fait (le premier compilateur Lisaac a été écrit en Eiffel d'ailleurs).

Bon, la aussi, le projet n'a pas l'air très vivace. Il bouge, on fait des choses, mais il reste encore à faire des releases propres et publier les dernières versions du compilateur Lisaac.

Si tout se passe bien, j'aimerais d'ailleurs bien porter Lisaac sur l'architecture LLVM. Ça serait vraiment bien.

Mono, un freeware ... il ne faut pas pousser quand même.

Mono reste libre, complètement et entièrement. Qu'il y ait ou non de possibles brevets qui le menace ne change rien à cela

Il faut ajouter nomodeset à la ligne de commande du kernel. Ça peut être aussi très utile avec des cartes intel qui ne marchent pas avec KMS.

J'utilise Fedora 11 (enfin, rawhide jusqu'à présent) et PulseAudio fonctionne très bien. J'avais eu pas mal de problèmes dans le passé, mais pas récamment.

Tiens, j'ai un instant pensé que ballados était le nom de la nouvelle fedora ... et j'ai pensé, quel nom pourri. Nous voila sauvés maintenant que nous savons exactement ce que veut dire ce mot :)

On m'avait 'offert' MS Office avec mon mac (intel) et il était compilé pour PPC uniquement, cependant, je suppose qu'il devait fonctionner très bien (je ne l'ai jamais installé).

On a la limite du nombre de clients sur un serveur X à 256. On peut penser que c'est suffisant, mais il faut croire que non. Ces derniers jours je n'ai pas cessé d'avoir des problèmes avec ça. Il y a en fait beaucoup plus de clients que de fenêtres visibles, par exemple, chaque applet sur le tableau de bord gnome est un client X11.

http://www.x.org/wiki/Development/X12#head-780a667e54dfccd19(...)

Vous pouvez essayer de lancer :

xlsclients
xwininfo -root -children

XMPP est beaucoup mieux armé face aux spams que le mail.

D'abord, il y a une whitelist (c'est ta liste de contact)
Ensuite, il n'y a pas vraiment moyen de faire des messages anonymes, c'est ce qui permet aux spams par mail d'être si nombreux.

Donc, oui, même si le spam par XMPP est une éventualité, je pense que le contrer sera aussi beaucoup plus facile.

Et lorsqu'on aura plus que XMPP comme système de messagerie, on dira adieu aux mails classiques et à leur spams. Sauf peut être pour les listes de diffusion, mais là, les spams ne sont pas un problème car souvent, les listes ont un header List-Id qui permet de voir d'où vient le message. Son absence sera synonyme de spam (les messages personnels passant par XMPP).

Je trouve cette remarque sur XMPP complètement pertinente.

A mon avis, l'e-mail se meurt. Sa maladie: les spams. Il y a peut être des cures, mais je les attend toujours. le filtre anti-spam ne peux à mon avis qu'être comparé à un anti-douleur qui tente de masquer le problème sans le résoudre.

Pourtant, j'aime bien les e-mails. Mais il faut le moderniser pour l'Internet d'aujourd'hui.

Et XMPP semble une bonne solution.
XMPP est souvent défini comme un protocole de messagerie instantanée, mais c'est plus que ça. Avec la possibilité d'envoyer des messages offline avec une ligne de sujet, ça se rapproche de l'e-mail.

Je ne doute pas qu'il manque encore des fonctionnalités par rapport au mail, mais les XEP sont pour ça. En attendant, je pense que XMPP pourrait être utilisé comme protocole de messagerie non instantanée. Je pense que cela serait même très bénéfique.

Sans compter que cela permettrait de résoudre certains problèmes rencontrés avec les e-mails. J'entend encore souvent des personnes se plaindre qu'ils n'arrivent pas à lire certains messages, avec des signes cabalistiques ... Sans compter la dualité du format texte brut sur 72 colonnes et HTML. Un format unifié comme propose XMPP semble une bonne solution.

J'attend donc avec impatience que XMPP prenne ce chemin, et je pourrais alors enfin dire adieu aux spams.

Mildred

Ta proposition de séparer mail/agenda ne répond pas au problème des gens qui demande cet intégration, à savoir recevoir une invit' par mail, cliquer sur oui/non/répondre (cette troisième voie étant pour demander des précisions pas exemple, pour ensuite cliquer sur oui/non dans la réponse du premier émetteur)

Pour l'intégration, on doit pouvoir passer par une interface dBus standardisée je pense. Par contre, il faudrait qu'un groupe de travail se forme sur ce concept. Peut être freedesktop.org ...

Je pense personnellement qu'on devrait séparer le "client mail" ainsi:
- un carnet d'adresse séparé
- un logiciel de visualisation de mail
- un logiciel de composition de mails
- un logiciel de récupération de mails (et filtrage éventuellement)
- un gestionnaire de fichiers permettant d'afficher les e-mails de manière intelligente (vue des threads, affichage des données du mail, sujet, date, expéditeur ...)
- un calendrier séparé

On en est bien loin :(

Je peux vous dire que chez moi ça ne marche pas ... La prise USB de ma souris ne rentre pas du tout dans le port Ethernet

Pour un projet avec une entreprise, on avait le choix entre une solution Java/Swing, Qt/C++ ou Qt Jambi. Personnellement j'aurais bien aimé Qt jambi mais finalement on a décidé ce matin de choisir Qt C++.

C'est vraiment dommage que Qt Jambi s'arrête. J'ai un peu programmé avec (des petits programmes exemple) et c'était vraiment agréable. Et niveau langage, je préfère à priori Java à C++ (même si heureusement le C++ utilisé avec Qt est une version simplifiée)

Ce qui me frappe aussi c'est le nombre de processus lancés au démarrage. Il suffit de voir le PID du dernier processus. De mémoire, sur mon Linux, je tourne aux alentours de quelques milliers.

Et sur Mac OS (qui est plus rapide), c'est de l'ordre de 200.

Je me demande si il ne serait pas possible de réduire drastiquement le temps de démarrage si on arrêtait d'utiliser des scripts shell, mais par exemple des langages de scripts légers, et utiliser des bibliothèques.

Par exemple au lieu de lancer l'exécutable modprobe (par exemple) juste utiliser une fonction dans une bibliothèque qui ferait la même chose.

Te faire le chantre de la philosophie du libre, toi le suporter de Mono, le cheval de troie de MS, ça me fait penser à Fabius qui se fait le chantre de l'extrême gauche, c'est un peu fort de café.

Qu'est ce que tu peux bien avoir contre Mono, c'est un logiciel libre. Il permet d'utiliser des langages super bien, super facilement. Le seul reproche que je peux faire c'est l'inexistence de la documentation sur dbus-sharp :/

Je vois pas trop ce que vous espérez avec Lisaac : vous n'avez clairement pas les moyens de faire un langage "industriel". Donc en soit c'est un projet uniquement destiné à être un prototype de laboratoire sans autre avenir que de l'étriper pour y extraire les bonnes idées et les mettre ailleurs.
Ah ? Pourquoi n'aurait-on pas les moyens de rendre Lisaac utilisable comme langage "industriel" (je suppose que tu parles ici des nombreux manques dont j'ai déjà parlé). Le problème c'est que pour le moment, j'ai l'impression d'être la seule personne dans l'équipe à avoir conscience de ces problèmes (peut être pas, mais c'est mon impression). Ce n'est pas je pense un manque de moyens.

Étriper le langage est une possibilité, mais je ne pense pas que ce soit la bonne. Cela voudrait dire que les qualités de Lisaac seraient séparés ... alors que je pense que c'est justement leur réunion qui donne toute sa qualité au langage.

Y'a une autre possibilité : profiter des "ressources" de la communauté des logiciels libres pour tenter de rendre le projet utilisable et utilisé. Pourtant vous n'avez pas choisi non plus cette voie. Bon courage !

C'est en partie la voie choisie (rappel: le compilateur n'était pas libre avant). Le problème c'est que Benoît n'est pas encore sûr de son choix. Mais le compilateur est libre (y compris la dernière version même si elle n'est pas publiée encore. Mais elle le sera, sans aucun doute).

Ce qui m'étonne c'est qu'à la libération du langage, j'ai été la seule personne à participer au projet. Tout était libre, mais pas grand monde de la comunauté n'est venu.

Alors, quand tu laisse entandre que Lisaac tourne le dos à cette comunauté, laisse moi être en profond désacord avec toi. Seulement, il faut comprendre qu'une libération de logiciel ne se fait pas aussi simplement. Il y a toujours une période de transition (qui dans ce cas est particulièrement longue, je pense par manque d'interêt de la comunauté justement).

Cependant, je m'engage (dans la limite de mes possibilités, toujours) à faire de Lisaac un langage moderne et utilisable au quotidien, comme n'importe quel autre langage. Et libre.

Pour ça, mieux vaut un dépot mercurial, git ou bzr ... Parce qu'il ne nécessaite pas de repository central. Le repository est confondu avec ta copie de travail.

En gros, pas besoin de faire un repository svn (un peu lourd à faire) pour chaque document.

En gros vous refusez pertinemment de partager de l'information. Vous avez peut être de bonnes raisons professionnelles, mais ici c'est LinuxFR, et ça va être dur de vous justifier...

On à besoin de se justifier ?

Personnellement, je préfèrerais que le projet soit plus ouvert ... mais c'est déjà une évolution par rapport à avant où il n'était même pas libre.

Il faut aussi comprendre que Lisaac, cela représente vraiment tout pour Benoît qui en est à l'origine. Il à fait un travail fantastique sur certains points (même si le langage n'est pas encore prêt), ce serait injuste je pense que le projet ne marche pas.

De plus, Lisaac est la base de ses travaus de recherche. Souvent il implémente une fonctionnalité avant d'avoir rédigé le papier correspondant. Ce serait injuste que quelqu'un d'autre reprenne son travail pour publier un papier à sa place alors que c'est lui qui l'a implémenté.

Certes, ce n'est pas très ouvert, mais le monde n'est pas un monde parfait. Il faut malhereusement se protéger un peu si on veut pouvoir y survivre. Finalement, je trouve que c'est le bon choix car j'ai l'impression que peu de chercheurs produisent vraiment du code utile comme ça.

Les objets pouvant être accédés par plusieurs threads sont simplements rendus immuables (on ne peux plus les modifier). Et pour l'implémentation, je ne sais pas encore, demander à Benoît.

facebook prévoir que sa messagerie devienne compatible xmpp/jabber ... mais je crois qu'il n'y a qu'une seule personne y travaillant donc ça avence lentement.

Moi, je ne t'invite pas encore à tester ... j'ai peur que tu sois déçu par justement la difficulté de programmation. En gros, plein de choses sont encore trop difficiles à faire. Revenir à la gestion des erreurs comme ne C est quelque peu troublant ...

C'est bien gentil d'avoir de l'héritage multiple ou de pouvoir changer le parent. Mais dans bien des cas, c'est inutile. C'est joli, mais on s'en passe facilement. Par contre, devoir gérer chaque cas exceptionnel à la main, c'est pas super :/

Sinon, t'as déjà codé en Lisaac ?
Oui, et Lisaac manque de plein de fonctionnalités élémentaires :(

désolée de casser le mythe du parfait langage, j'espère que ce sera le cas un jour, mais pas encore.

De plus, la gestion d'erreur n'est PAS élémentaire. Les modules ne sont PAS non plus élémentaires. On essaie de faire quelque chose d'innovant et ça prend du temps.

Pour un langage qui se dit de haut niveau, si :)

Mais je commence à douter que Lisaac soit si haut niveau. En tout cas son code source est très bas niveau :)

Lisaac est un langage qui ne propose pas de gestion des erreurs, qui ne propose pas de gestion des modules, bref des choses élémentaires qui ont directement un impact sur les perfs : alors revenez avec un langage un minimum complet, après on refera les benchs et on comparera les perfs avec ce que fait MS (ou autre hein, y'a pas que MS).

Lisaac n'est pas encore prêt. Et pour ma part, je n'ai jamais prétendu le contraire. Mais je travaille sur ces sujets importants (lorsque j'ai le temps et la possibilité, c'est à dire quand j'ai accès à des sources assez récentes (pas d'il y a deux ans) et qui compilent :)