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 :/

[ Répondre ]

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.

[ Répondre ]

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.

[ Répondre ]

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.

[ Répondre ]

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.

[ Répondre ]

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.

[ Répondre ]

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 :/

[ Répondre ]

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.

[ Répondre ]

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 :)

[ Répondre ]

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 :)

[ Répondre ]

Excuse du peu, mais Lisaac se veut un langage pour faire un OS, et les exceptions existent aussi en C# (que certains utilisent pour faire un OS), en C++ (dont l'utilisation dans les OS n'est plus à démontrer).
Donc voilà, je me doute que c'est dans les priorité, mais j'aimerai savoir si vous avez avancé sur le sujet, parcque dans les derniers débats que j'avais eu, la notion de module avait l'air de foutre en l'air la notion d'optimisation global offerte par le compilo...

L'aspect OS était ces derniers temps en train de disparaître, même si il se met peu à peu à revivre ...

Pour les modules qui fouttent en l'air l'optimisation globale, c'est vrai. Mais il n'y a pas de solution miracle. Par contre, si l'application est bien développée, les interfaces entres modules seront réduites, ce qui permettra d'optimiser chaque module séparément comme avant, et de ne perdre que peu de performances à l'endroit des interfaces.

C'est mon idée en tout cas. Mais pour le moment il n'y a aucun code de ce coté. Mais c'est prévu: http://mildred817.online.fr/Misc/Computer/Lisaac/Specs/Futur(...)

(note, ce sont mes idées, cela ne sera probablement pas intégré dans Lisaac tel quel)

[ Répondre ]

Vous semblez critiquez la notion d'exception, pourquoi pas, mais où sont les arguments/raisonnement ?

Perso, je n'ai rien contre, c'est plus Benoît, l'inventeur du langage qui ne les aime pas. Il me semble que le problème c'est que cela cause une rupture de flot (un peu comme les goto, les break, continue et return qui n'existent pas en Lisaac). Cette rupture de flot pose un problème il semblerait au niveau de la preuve des programmes par les contrats.

Mais je ne peux pas en dire plus, je n'en sais rien en fait.

[ Répondre ]

Il me semble que wget conserve la date du document. J'ai pu m'en rendre compte car j'ai un dossier spécial ~/Inbox qui sert à recevoir tous les téléchargements que je fais. Et je le trie par date.
Les fichiers téléchargés par firefox viennent s'ajouter à la fin, mais avec wget, c'est au milieu.

[ Répondre ]

On pourrait imaginer que l'application de mise à jour se personnalise avec le logo de la boîte et le nom de la boîte ... ça n'aurait pas du tout l'air de venir de Microsoft.

Par exemple, si ça s'appelle update.exe, lors de l'installation d'un programme, un raccourci vers update.exe est placé dans le menu démarrer avec en paramètres un fichier de configuration.

Et pour les problèmes de malware, ne suffirait-il pas d'exiger un serveur ayant un certificat de sécurité validé ?

En gros cela ressemblerait aux programmes de mise à jour que chaque boîte fait dans son coin, mais avec une base commune.

[ Répondre ]

Je ne veux pas être désagréable mais bon ... Il y a un moment ou il faut arrêter de pleurer et agir.

C'est pas toujours facile d'agir, tu fais comment en pratique.

En parler ici est une forme d'action. Cela permet de partager ses idées, de montrer aux autres les problèmes, de chercher des solutions éventuellement. Pour ma part, je suis d'accord avec lui sur bien des points, mais il reste la question de comment contribuer ?

Le problème c'est qu'un individu dans son coin aura du mal à contribuer car il aura peu d'influence, les autres ne voyant pas le problème.

[ Répondre ]

Je pense plutôt que si tu propose une interface standardisée, tu risque de te faire jeter avec pour prétexte “ça sert à rien ton truc”.

J'ai fait quelques essais (certes, pleins d'erreurs) sur la mailing list XDG (normalisation de freedesktop) -> aucune réponse. Sans doute personne ne percevait le besoin que j'avais. Il y avait peut être une personne qui m'a contactée pour me demander si j'avais réussi à aller quelque part, eh ben non.

Peut être devrais-je faire partie d'une équipe GNOME ou KDE, ça marcherait peut être mieux. Mais je ne peux pas m'y résoudre, trouvant des défaut dans chacun des deux environnements (et dans X11 plus globalement, le Grab du pointeur est souvent gênant, car empêche les autres applications d'avoir des informations importantes sur l'activité de l'utilisateur)

[ Répondre ]

Cela dit aujourd'hui, les WM font des tas de trucs qu'ils ne devraient pas faire (gestion du réseau, accès aux FS, etc ...) et c'est vrai que ça devient n'importe quoi.

Je rêve d'un monde où les services session utilisateurs soient intégrés au maximum au système, pour pouvoir choisir son WM préféré qui n'a pas forcément tout développer, et continuer à pouvoir avoir une gestion de l'énergie.

Ou au moins, d'un monde où ces services de session ne soient pas liés à un WM.

Je trouve l'approche de NetworkManager mieux que celle prise pour la gestion de l'énergie. On a un daemon NetworkManager qui gère les connexions, sauf que le daemon qui gère la gestion de l'énergie doit être implémentée pour chaque WM.
Le mieux, ce serait une daemon se chargeant de la gestion de l'énergie, et une interface dBus pour le controller. Cela éviterait par la même occasion de devoir implémenter la gestion de l'énergie dans gdm.

[ Répondre ]

Quand aux packages, j'ai peu d'espoir d'unification deb et rpm!

Pas besoin d'unifier deb et rpm. Ces packages là sont fait par les distributions. A mon avis ce qui est nécessaire c'est de distinguer dans les distributions les packages fournis par la distribution, et les packages d'une tierce partie. Ces derniers peuvent utiliser un autre format (mieux vaut un format complètement nouveau sinon il y aura toujours des déçus qui auraient préféré voir leur format adopté).

Pour ma part, je pense que commencer avec une solution minimale serait une bonne solution, quitte a l'améliorer par la suite. J'imagine déjà la possibilité avec PackageKit d'installer un paquet externe à la distribution. Le format serait un simple tar.gz contenant les binaires, sans rien d'autre. Sans méta-information.

C'est rudimentaire, mais ce serait déjà une avancée je pense. On pourrait sur son site web proposer le paquet, et il marcherait partout (même sur les distributions qui n'ont pas PackageKit, un simple tar xf suffirait). L'interêt de PackageKit serait que les fichiers seraient pris en compte par le système de paquets.

[ Répondre ]

Freedesktop est une bonne idée, encore trop limitée. Mais il faut travailler dur pour aller plus loin (quelle autre solution a-t-on de toute façon ?)

[ Répondre ]

Ce n’est pas le développeur des applications qui proposent ce choix (lui il développe, son application c’est celle qui est dans le svn, il s’en tape des versions précédentes — en tant que dév.)

Dans certains cas, les dev. peuvent proposer ce choix. Tous ne sont pas uniquement dans leur svn (ou mercurial, c'est mieux) ... Par exemple des applications comme Firefox ou OpenOffice.org. Ces applications ont un suivi qualité, et si les dev. décident qu'une nouvelle version est stable, on peut leur faire confiance.

L'argumentaire classique revient à faire de l'utilisateur d'une distribution le “client” de cette dernière. Il utilise les applications de la distribution. Sauf que dans certains cas, l'utilisateur final n'a pas forcément ce désir ... et se sent d'avantage “client” du groupe de dev. qui font l'application (Firefox, OpenOffice.org, wine et j'en passe).

Dans ce dernier cas, il n'existe aucun outil pour faciliter le déploiment de telles applications, et on se retrouve très souvent à compiler à la main en outrepassant le système de paquets local (chose que je déteste, le système de paquet est utile dans le mesure où il recense tous les fichiers du système).

ah dans ce cas là je suivais de près les sortis noyaux en outre-passant ma distribution. Il n’y a pas 36 000 solutions si on veut la dernière version d’un logiciel X tout de suite

C'est cela que je regrette, le manque de solutions (techniquement faisable) face à un problème que pas mal de monde s'est posé où se posera au moins un jour dans sa vie de linuxien.

Sauf que pour le moment le public linuxien sait en majorité compiler les applications à la main. Mais il faut penser aux gens qui aiment linux sans forcément savoir compiler (et sans forcément pouvoir apprendre). J'en connais.

[ Répondre ]