Tout à fait d'accord avec toi, une application en web en local n'a pas de soucis de dépendance du bon fonctionnement de la liaison internet, mais comme je l'indiquais, nous ne somme pas convaincu de la pertinence du "tout navigateur" pour faire une application de gestion en réseau (local).
Un forum, un webmail, un CMS ou un bugtracker c'est très bien dans un navigateur, mais quand il faut commencer à discuter avec une imprimante série, une douchette code à barres et un tiroir caisse... on est bien content d'avoir un peu plus que HTML/CSS/JavaScript.
Pour faire court, disons que développer une application web c'est avant tout se battre contre les limitations des navigateurs, la latence réseau et les débits pas toujours terribles.
Côté "OnCloud", OpenConcerto est techniquement prêt. Base de données sur le cloud et logiciel lancé en utilisant webstart, ca fonctionne très bien sur une liaison 3G.
L'interface graphique du logiciel étant asynchrone, les problèmes liés à la latence et aux débits sont résolus. Nous avons des clients qui utilisent le logiciel à travers des liaisons VPNs en ADSL pour faire du multisite et multisociété et sont ravis de voir que les performances sont là.
Pour donner une idée des limitations que nous ne voulions pas avoir, voici un exemple concret: l'édition de facture.
Imaginons qu'un client ait dans sa "procédure qualité" la contrainte qu'une facture doit être toujours imprimée en 2 exemplaires (une pour la société, une pour le client):
- Un ERP web, proposera un bouton "imprimer" qui créera la facture (souvent en PDF) sur le serveur, l'enverra au navigateur de l'utilisateur, la visionneuse du système prendra le relais pour afficher le document, l'utilisateur cliquera "imprimer", 2 fois. Cela prend plusieurs clics et plusieurs secondes.
- Avec OpenConcerto, le bouton imprimer peut lancer directement l'impression sur l'imprimante en 2 exemplaires sans rien demander à l'utilisateur. On pourrait même mémoriser qui imprime quoi et quand.
Pour le tester, le plus simple est de télécharger la version monoposte, prête à l'emploi.
Sous linux, il y a un script ".sh", pour windows un exe et sous MacOS le .app qui va bien. Dans tous les cas, quelques double clic s (voir triple clics) suffiront.
Le code source arrive "bientôt", nous avons besoin d'encore un peu de temps pour factoriser des petites choses. Et comme du code sans documentation, ça ne sert a rien, on se donne quelques jours supplémentaires pour écrire de quoi bien démarrer.
Merci. 500 visites sur le site ce jour d'après google analytics, c'est encourageant.
GestionNX c'est le nom commercial de l'ancêtre de OpenConcerto. On peut voir OpenConcerto comme une synthèse des différents développements spécifiques que nous avons pu faire autours de GestionNX. L'idée est de monter en puissance niveau fonctionnalité, sous forme de modules, autours d'un noyau et réaliser les développements spécifiques en modules.
Je vois plutôt OpenConcerto comme une autre solution libre, pas vraiment un concurrent à un autre projet libre. La concurrence est à chercher du côté des éditeurs de logiciels propriétaires.
La grande différence technique est que nous avons fait le choix de ne pas baser le logiciel sur des technologies web. Pour le confort d'utilisation bien sûr, mais également pour éviter de bloquer les clients en cas de coupure internet (s'il part dans une offre hébergée).
La page support est corrigée. Merci de l'avoir signalé, il y a tellement de choses à vérifier lors d'une mise en ligne... et les yeux finissent par ne plus rien voir!
Pour la caisse, bien vu, c'est un exécutable à part que nous n'avons pas inclus pour la version 1.0. Non pas qu'elle soit non fonctionnelle, mais nécessite d'écrire une documentation. Encore un peu de patience ;)
S'interfacer aux douchettes et imprimantes tickets n'est pas forcément aisé, car ces matériels sont loin de suivre des standards. Si tu connais par coeur les modèles de matériel POS que tu veux utiliser, je me ferrais un plaisir de t'indiquer si la version actuelle est compatible.
Pas encore eu le temps d'évaluer en détail OpenBravo POS, mais je ne vois pas ce qui empêcherais de coder un import.
Pour accrocs du Java côté serveur, vous pouvez faire un tour du côté de jOpenDocument.org pour générer et manipuler des fichiers au format OpenDocument.
Très bonne remarque!
La règle la plus commune est d'arrondir chaque total afin que la somme fasse bien la somme des montants affichée (tronqués a 2 chiffres après la virgule), sinon "la" comptable va pas comprendre pourquoi 10.00 + 20.00 ca fait 30.01.
La gestion derrière, que ce soit en centimes entiers ou euros en nombres décimaux, c'est un choix. J'ai déjà vu pas pas de newbies gérer tout ca en flottant :) un vrai régal d'erreur.
8.1 stable... oui si on veut, pour avoir perdu 48h à essayer de monter un NAS ZFS+Samba avec, je ne dirais pas "boulversifiant".
Core 2 duo E7500, 8Go de mémoire, 3 DD SATA de 2To, 1 petit SSD pour le cache et c'est parti:
- samba reste bloqué à chaque connexion, sans workaround trouvé. Le problème semble assez fréquent
- pas de support du "trim" pour le SSD
- le ZFS de FreeBSD est loin d'être la dernière version, pas de déduplication et des bugfixes non inclus
Bref, sans déduplication et sans samba, reboot et install de nexenta... sans aucuns soucis. (débit 90Mo/s en lecture, et 60Mo/s en écriture avec compression gzip et déduplication)
Je me souviens d'un article sur Login expliquant que pour Intel et AMD, il est indispensable economiquement de complexifier les architectures des processeurs en augmentant le nombre de transistors.
En effet, a nombre de transistor egal, l'evolution des process de production, nous aurions dans 5 ans des Core2Duo a 12 GHz pour 10 euros!
Encore un peu de patience et le x86 sera juste un coprocesseur integre de serie a tout processeur afin de garantir la compatibilite des applications industrielles. Applications pour lesquelles un changement d'archi ne serait qu'une perte financiere sans le moindre gain de fiabilite, ou de fonctionnalite ou de performance...
Un format ne devient un standard que par son adoption massive par les utilisateurs.
OpenOffice par sa gratuité a un avantage immense pour l'utilisateur mais au niveau des développeurs, Microsoft est loin devant.
On ne compte plus le nombre d'applications qui s'interfacent à Word pour générer des documents, les afficher, ou encore les librairies .net (bien sur!) et Java pour manipuler le OOXML.
Côté OpenDocument, il reste UNO + OpenOffice, bien lourd à utiliser et peu de librairies. ( même si on si atèle activement sur http://www.jopendocument.org )
Tour de passe passe et argent ni ferront à mon avis pas grand chose au final pour Microsoft, on l'a bien vu avec Firefox.
Le tout est de tenir la barre avec un bon format et de quoi l'exploiter facilement (si possible pour pas trop cher :) ), non?
Apres une demi journee de test du 2.6 'stable' voici mes premieres impressions:
- installation : pas dur du tout a partir d'une redhat 9, redhat fournit les rpms qui vont bien
- premier boot : tout marche ou presque : le son est OK, XFree sur une GeForce4 MX aussi, pas de problemes de stabilite a l'utilisation et aussi une grande rapidite de boot et un gain de reactivite avec XFree.
L'USB a necessite quelques modifs du rc.sysinit! Un petit reboot pour voir le resultat ...
- deuxieme boot: pas de problemes avec l'USB, l'imprimante laser marche toujours... le systeme de fichier depote; le bash ne traine plus pour une grosse copie ou un "tar -zxf ". Toujours plein d'espoir, je teste Mozilla, et la grosse stupeur, Mozilla mouline pendant presque 10s a chaque fois que j'accede a une nouvelle page, pareil pour un telechargement, j'essaye la derniere version de Mozilla, idem... Opera n'a pas ce probleme, il est encore plus veloce qu'avant, c'est dire! OpenOffice, Java, tout est plus rapide, que demander de plus?
Et c'est la que ca fait mal, le graveur de CDROM LG ne lis plus les CDs, en regardant les logs, pas d'erreur, ide-scsi se lance bien... le log du kernel montre que /dev/hdc est le graveur... mais rien, mount /dev/hdc /mnt/cdrom dis que /dev/hdc n'est pas valide... :(
Et maintenant, le test ultime pour la machine: un 'sync' en tant que root, j'attend 10s et debranche la prise...
- dernier boot: le disque est vu comme not clean, recovering journal (les partitions sont en ext3) et boom la verification du filesystem annonce le verdict, il faut faire un fsck a la main, qui apres 30 mins part en vrille, reboot la machine, un demi million d'erreurs sur le disk; bye bye 2.6
Reformatage complet pour un 2.4, au moins, ca plante pas tout au premier redemarrage brutal...
Pb de securite... J'ai l'impression que pour toi, gerer la transparence dans une fenetre, c'est avoir acces aux bitmaps des fenetres en dessous pour pouvoir calculer la superposition avec les canaux alpha... effectivement ca ne serait pas 'secure'.
C'est au server a gerer la transparence, c'est a lui de faire de faire les calculs qui vont bien pour que quand une appli fait trace qq chose, le resultat a l'ecran respecte les canaux alpha.
Avec la Xlib point de canaux alpha.... avec XRender c'est possible mais ca rame enormement. ( suffit de regarder le code source des drivers pour voir qu'il n'y a pas de support de l'alpha )
Pour ceux qui y croyaient encore, je rappelle qu'en local, X utilise les sockets Unix et la SHM
Voila un autre mythe!! Il n'y a pas 5% des applis qui utilisent SHM. SHM perment de partager des bitmaps entre le client et le serveur sans le transferer par socket. MAIS il faut explicitement utiliser l'API de SHM pour ca, une appli non designe pour utiliser SHM ne le ferra pas (meme inconsciement).
Ecrire des tonnes d'extension pour XFree ne sert a rien car quel developpeur vas redesigner son applis tous les 2 ans pour rajouter partout des tests genre:
si SHM est dispo et je suis en 'local' alors je l'utilise
si XRender est dispo et est accelere en hard alors je l'utilise
etc etc....
Cote perf, meme sans utiliser autre chose que du Xlib pur, les applis pourraient etre rapides, mais ca demande enormement de temps. Sous B.E.OS (www.BlueEyedOS.com), le pari a ete pris de faire ces optimisations cote server d'application du systeme. Du coup toutes les applications utilisant l'API de B.E.OS (qui est la meme que celle de BeOS) beneficient de toutes les accelerations possible cote serveur.
Immature, ça ne signifie pas savoir coder
Ou ai je ecris, bon coder implique mature?
J'aurais peut etre du ecrire, matures et bon coders. Fin de la parenthese. La division est venue de divergences techniques, pas politiques.
Pour reprendre, ce qui a été dit sur la GPL, la license n'aurait rien changé quand a la cause de la division. C'est une vision bien simpliste! [désolé, mais je fais partie de ceux qui ne reduisent pas l'informatique a un question de license et qui ne sont pas convaincu que "c'est opensource" ou "c'est GPL" donc c'est mieux.]
S'il y a division, ie si A eclate en B et C, C n'a rien a faire du code de B et vice versa. L'interet d'un developement fermé comme B.E.OS est bien d'eviter un tel eclatement (par la non reutilisabilte de A par B et C). Si B et C ne peuvent pas reutiliser A, la divergence est freinée sauf en cas d'approches totalement differentes.
En ce sens, les 2 projets menés par des ex-B.E.OS sont radicalement differents. La viabilté de chacuns des projets dependra plutot de leurs caracteristiques qui vont ou pas seduire les developpeurs.
Les gens qui désirent développer BlueEyedOS ne sont quand même pas immatures au point de faire forker le projet à chaque décision qui ne lui va pas, si ? Ça me donne l'impression de ne pas faire confiance aux développeurs.
Forker, je ne sais pas, mais tout remettre a sa sauce en creant un nouveau projet... oui. Ce qui est tres important pour un systeme d'exploitation c'est la coherence, qu'est ce qui va se passer si par exemple, qq'un decide de faire evoluer une librairie, et l'integre dans un B.E.OS like compatible a 99% ? AMHA, un bordel a court terme et un desinteret des utilisateurs qui ne vont plus s'y retrouver dans les versions...
Je me souviens tres bien des discussions que nous avons pu avoir en interne au sujet de ce que vous avez vu sur la partie1 de la demo, cad le systeme de fenetrage. Cette approche a ete critiqué largement, personne n'a ete capable de demontrer que son approche etait meilleure... au lieu de commencer a coder d'autres approches, 2 nouveaux projets sont apparus: SequelOS et LeonadoOS...
Pourtant ces 2 coders sont des pointures, loin d'etre immatures..
Maintenant credité de 2 XP, j'en profite pour apporter qq explications
pas essayé perso, mais il parrait qu'à part jouer à BePuyo et écouter 5038 (l'hymne BeOSien) il fait pas grand chose le CD.
Effectivement, vu de l'exterieur ca peut parraitre 'pas grand chose' et pourtant!
Reprenons ce qu'il contient:
. 'kernel_server', un server qui mappe plus ou moins directement les APIs kernel de BeOS vers du linux.
Si vous faites des tests de perfs entre BeOS et B.E.OS, vous allez etre surpris tant BeOS est a la traine.
. 'app_server', encore un serveur! Il gere de facon multithreadé (exactement comme le fait BeOS) l'affichage et la gestion des evenements (il y a 1 thread par fenetre cote userland et 1 autre cote app_server).
Le reste a peu d'importance, juste la pour la demo, comme le systeme de fenetrage (part1) balaye tout ce qu'on peut voir sous linux en terme de fluidite. (si l'autoconf a bien fait son travail en trouvant le bon driver video)
Moi j'ai essayé mais mon affichage était brouillé
Soit ta carte ne supporte pas le 24/32bits ou l'autoconfig n'a pas ete en mesure de trouver le bon driver.
Apparemment ils ont peur d'un fork c'est pourquoi ils n'ont pas pris la GPL ou LGPL.
Pas un fork en tant que tel, genre emacs/Xemacs, mais une evolution paralelle et inutile du projet. Genre les n logiciel IRC en version 0.2 qui on 90% de leur code basé sur un autre qui lui etait en version 0.5.2, bref un gros bordel comme le monde linux le connait.
Leur projet me parait tres interressant, le coté pragmatique de la chose me plait beaucoup, mais tant qu'il n'y aura pas de garantie que le code devienne ouvert, ça ne m'interesse pas.
Le code sera mis en license BSD si le projet stagne ou disparait. Pourquoi BSD? Simplement, parce que si cela arrive, c'est que l'on n'aura plus rien a faire de linux.
Des que l'OS sera utilisable, cad qu'il atteindra la version 1.0, le code sera ouvert.
Les forks existent, oui, mais il n'y en a pas toutes les 5 minutes.
Si on compte le nombre de mailers, de servers ftp, de logiciels irc, news etc... on doit
pas etre loin d'un projet paralelle toute les semaines.
B.E.OS , Lindows, Wine...
Si on avait voulu un genre de wrapper ou une sorte de toolkit, tout aurait ete mappé sur un QT ou GTK.
La ou B.E.OS differe c'est que le but est de faire un OS, pas une distribution 'BeOS compatible'.
Le systeme sera basé sur une 20ene de librairies maximum, et des applis 100% B.E.OS (ie n'utilisant que l'API B.E.OS). Aurevoir KDE, Gnome et tout ce petit monde d'applis mal foutues, qui entre autre ne sont pas capables d'avoir un fonctionnement ou un look homogene.
boot en 10s, etc...
Sur BeOS, l'affichage apparait en quelques secondes, mais il en faut encore quelques unes pour le reste des inits. Rien n'empeche de faire pareil sous linux, je l'ai deja fait.
Sur ma machine le CD de demo prend 1 minute avant de faire apparaitre l'affiche graphique. Ce qui est deja tres rapide vu que le filesystem est compressé et tourne sur CD!
Sans compter, l'autoconfig qui prend les 3/4 du temps...
[^] # Re: Mocèle de développement / financement...
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.0 , un nouvel ERP libre. Évalué à 1.
Pour les screenshots, je m'y colle la semaine prochaine en oubliant pas aussi de compléter le site avec les remarques de vous tous.
[^] # Re: Wow
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.0 , un nouvel ERP libre. Évalué à 3.
Un forum, un webmail, un CMS ou un bugtracker c'est très bien dans un navigateur, mais quand il faut commencer à discuter avec une imprimante série, une douchette code à barres et un tiroir caisse... on est bien content d'avoir un peu plus que HTML/CSS/JavaScript.
[^] # Re: Application riche
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.0 , un nouvel ERP libre. Évalué à 3.
Côté "OnCloud", OpenConcerto est techniquement prêt. Base de données sur le cloud et logiciel lancé en utilisant webstart, ca fonctionne très bien sur une liaison 3G.
L'interface graphique du logiciel étant asynchrone, les problèmes liés à la latence et aux débits sont résolus. Nous avons des clients qui utilisent le logiciel à travers des liaisons VPNs en ADSL pour faire du multisite et multisociété et sont ravis de voir que les performances sont là.
Pour donner une idée des limitations que nous ne voulions pas avoir, voici un exemple concret: l'édition de facture.
Imaginons qu'un client ait dans sa "procédure qualité" la contrainte qu'une facture doit être toujours imprimée en 2 exemplaires (une pour la société, une pour le client):
- Un ERP web, proposera un bouton "imprimer" qui créera la facture (souvent en PDF) sur le serveur, l'enverra au navigateur de l'utilisateur, la visionneuse du système prendra le relais pour afficher le document, l'utilisateur cliquera "imprimer", 2 fois. Cela prend plusieurs clics et plusieurs secondes.
- Avec OpenConcerto, le bouton imprimer peut lancer directement l'impression sur l'imprimante en 2 exemplaires sans rien demander à l'utilisateur. On pourrait même mémoriser qui imprime quoi et quand.
[^] # Re: Code source et installation
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.0 , un nouvel ERP libre. Évalué à 3.
Sous linux, il y a un script ".sh", pour windows un exe et sous MacOS le .app qui va bien. Dans tous les cas, quelques double clic s (voir triple clics) suffiront.
Le code source arrive "bientôt", nous avons besoin d'encore un peu de temps pour factoriser des petites choses. Et comme du code sans documentation, ça ne sert a rien, on se donne quelques jours supplémentaires pour écrire de quoi bien démarrer.
Bons tests!
[^] # Re: Wow
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.0 , un nouvel ERP libre. Évalué à 2.
GestionNX c'est le nom commercial de l'ancêtre de OpenConcerto. On peut voir OpenConcerto comme une synthèse des différents développements spécifiques que nous avons pu faire autours de GestionNX. L'idée est de monter en puissance niveau fonctionnalité, sous forme de modules, autours d'un noyau et réaliser les développements spécifiques en modules.
Je vois plutôt OpenConcerto comme une autre solution libre, pas vraiment un concurrent à un autre projet libre. La concurrence est à chercher du côté des éditeurs de logiciels propriétaires.
La grande différence technique est que nous avons fait le choix de ne pas baser le logiciel sur des technologies web. Pour le confort d'utilisation bien sûr, mais également pour éviter de bloquer les clients en cas de coupure internet (s'il part dans une offre hébergée).
[^] # Re: Ou es le module de caisse ?
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.0 , un nouvel ERP libre. Évalué à 3.
Pour la caisse, bien vu, c'est un exécutable à part que nous n'avons pas inclus pour la version 1.0. Non pas qu'elle soit non fonctionnelle, mais nécessite d'écrire une documentation. Encore un peu de patience ;)
S'interfacer aux douchettes et imprimantes tickets n'est pas forcément aisé, car ces matériels sont loin de suivre des standards. Si tu connais par coeur les modèles de matériel POS que tu veux utiliser, je me ferrais un plaisir de t'indiquer si la version actuelle est compatible.
Pas encore eu le temps d'évaluer en détail OpenBravo POS, mais je ne vois pas ce qui empêcherais de coder un import.
# Pour le site web Java
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Un point sur l'export ODT pour les applications web. Évalué à 2.
Les performances sont au rendez-vous.
[^] # Re: Il faut saluer les développeurs
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche PhpCompta sortie de la version 5.2. Évalué à 3.
La règle la plus commune est d'arrondir chaque total afin que la somme fasse bien la somme des montants affichée (tronqués a 2 chiffres après la virgule), sinon "la" comptable va pas comprendre pourquoi 10.00 + 20.00 ca fait 30.01.
La gestion derrière, que ce soit en centimes entiers ou euros en nombres décimaux, c'est un choix. J'ai déjà vu pas pas de newbies gérer tout ca en flottant :) un vrai régal d'erreur.
[^] # Re: Stable...
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Sortie de FreeBSD 8.1-RELEASE. Évalué à 2.
# Stable...
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Sortie de FreeBSD 8.1-RELEASE. Évalué à 3.
Core 2 duo E7500, 8Go de mémoire, 3 DD SATA de 2To, 1 petit SSD pour le cache et c'est parti:
- samba reste bloqué à chaque connexion, sans workaround trouvé. Le problème semble assez fréquent
- pas de support du "trim" pour le SSD
- le ZFS de FreeBSD est loin d'être la dernière version, pas de déduplication et des bugfixes non inclus
Bref, sans déduplication et sans samba, reboot et install de nexenta... sans aucuns soucis. (débit 90Mo/s en lecture, et 60Mo/s en écriture avec compression gzip et déduplication)
Guillaume
[^] # Re: Je suis pas fashion, je sais...
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche La virtualisation et le libre : où en est-on ?. Évalué à 2.
En effet, a nombre de transistor egal, l'evolution des process de production, nous aurions dans 5 ans des Core2Duo a 12 GHz pour 10 euros!
Encore un peu de patience et le x86 sera juste un coprocesseur integre de serie a tout processeur afin de garantir la compatibilite des applications industrielles. Applications pour lesquelles un changement d'archi ne serait qu'une perte financiere sans le moindre gain de fiabilite, ou de fonctionnalite ou de performance...
Je dois etre demode aussi ! ;)
# Verroux
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche La normalisation de OOXML relance le RGI.. Évalué à 1.
Un format ne devient un standard que par son adoption massive par les utilisateurs.
OpenOffice par sa gratuité a un avantage immense pour l'utilisateur mais au niveau des développeurs, Microsoft est loin devant.
On ne compte plus le nombre d'applications qui s'interfacent à Word pour générer des documents, les afficher, ou encore les librairies .net (bien sur!) et Java pour manipuler le OOXML.
Côté OpenDocument, il reste UNO + OpenOffice, bien lourd à utiliser et peu de librairies. ( même si on si atèle activement sur http://www.jopendocument.org )
Tour de passe passe et argent ni ferront à mon avis pas grand chose au final pour Microsoft, on l'a bien vu avec Firefox.
Le tout est de tenir la barre avec un bon format et de quoi l'exploiter facilement (si possible pour pas trop cher :) ), non?
# Pas encore pour moi
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Le noyau Linux 2.6.0 annoncé stable. Évalué à 1.
- installation : pas dur du tout a partir d'une redhat 9, redhat fournit les rpms qui vont bien
- premier boot : tout marche ou presque : le son est OK, XFree sur une GeForce4 MX aussi, pas de problemes de stabilite a l'utilisation et aussi une grande rapidite de boot et un gain de reactivite avec XFree.
L'USB a necessite quelques modifs du rc.sysinit! Un petit reboot pour voir le resultat ...
- deuxieme boot: pas de problemes avec l'USB, l'imprimante laser marche toujours... le systeme de fichier depote; le bash ne traine plus pour une grosse copie ou un "tar -zxf ". Toujours plein d'espoir, je teste Mozilla, et la grosse stupeur, Mozilla mouline pendant presque 10s a chaque fois que j'accede a une nouvelle page, pareil pour un telechargement, j'essaye la derniere version de Mozilla, idem... Opera n'a pas ce probleme, il est encore plus veloce qu'avant, c'est dire! OpenOffice, Java, tout est plus rapide, que demander de plus?
Et c'est la que ca fait mal, le graveur de CDROM LG ne lis plus les CDs, en regardant les logs, pas d'erreur, ide-scsi se lance bien... le log du kernel montre que /dev/hdc est le graveur... mais rien, mount /dev/hdc /mnt/cdrom dis que /dev/hdc n'est pas valide... :(
Et maintenant, le test ultime pour la machine: un 'sync' en tant que root, j'attend 10s et debranche la prise...
- dernier boot: le disque est vu comme not clean, recovering journal (les partitions sont en ext3) et boom la verification du filesystem annonce le verdict, il faut faire un fsck a la main, qui apres 30 mins part en vrille, reboot la machine, un demi million d'erreurs sur le disk; bye bye 2.6
Reformatage complet pour un 2.4, au moins, ca plante pas tout au premier redemarrage brutal...
Guillaume
[^] # Re: Après X, voici Y...
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Après X, voici Y.... Évalué à 1.
Pb de securite... J'ai l'impression que pour toi, gerer la transparence dans une fenetre, c'est avoir acces aux bitmaps des fenetres en dessous pour pouvoir calculer la superposition avec les canaux alpha... effectivement ca ne serait pas 'secure'.
C'est au server a gerer la transparence, c'est a lui de faire de faire les calculs qui vont bien pour que quand une appli fait trace qq chose, le resultat a l'ecran respecte les canaux alpha.
Avec la Xlib point de canaux alpha.... avec XRender c'est possible mais ca rame enormement. ( suffit de regarder le code source des drivers pour voir qu'il n'y a pas de support de l'alpha )
[^] # Re: Après X, voici Y...
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Après X, voici Y.... Évalué à 1.
Voila un autre mythe!! Il n'y a pas 5% des applis qui utilisent SHM. SHM perment de partager des bitmaps entre le client et le serveur sans le transferer par socket. MAIS il faut explicitement utiliser l'API de SHM pour ca, une appli non designe pour utiliser SHM ne le ferra pas (meme inconsciement).
Ecrire des tonnes d'extension pour XFree ne sert a rien car quel developpeur vas redesigner son applis tous les 2 ans pour rajouter partout des tests genre:
si SHM est dispo et je suis en 'local' alors je l'utilise
si XRender est dispo et est accelere en hard alors je l'utilise
etc etc....
Les problemes de X sont exposes ici:
http://www.osnews.com/story.php?news_id=1905(...)
Cote perf, meme sans utiliser autre chose que du Xlib pur, les applis pourraient etre rapides, mais ca demande enormement de temps. Sous B.E.OS (www.BlueEyedOS.com), le pari a ete pris de faire ces optimisations cote server d'application du systeme. Du coup toutes les applications utilisant l'API de B.E.OS (qui est la meme que celle de BeOS) beneficient de toutes les accelerations possible cote serveur.
[^] # BlaBla
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Le CD de démo de BluEyedOS est disponible. Évalué à -1.
Ou ai je ecris, bon coder implique mature?
J'aurais peut etre du ecrire, matures et bon coders. Fin de la parenthese. La division est venue de divergences techniques, pas politiques.
Pour reprendre, ce qui a été dit sur la GPL, la license n'aurait rien changé quand a la cause de la division. C'est une vision bien simpliste! [désolé, mais je fais partie de ceux qui ne reduisent pas l'informatique a un question de license et qui ne sont pas convaincu que "c'est opensource" ou "c'est GPL" donc c'est mieux.]
S'il y a division, ie si A eclate en B et C, C n'a rien a faire du code de B et vice versa. L'interet d'un developement fermé comme B.E.OS est bien d'eviter un tel eclatement (par la non reutilisabilte de A par B et C). Si B et C ne peuvent pas reutiliser A, la divergence est freinée sauf en cas d'approches totalement differentes.
En ce sens, les 2 projets menés par des ex-B.E.OS sont radicalement differents. La viabilté de chacuns des projets dependra plutot de leurs caracteristiques qui vont ou pas seduire les developpeurs.
[^] # Re: La
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Le CD de démo de BluEyedOS est disponible. Évalué à 0.
Forker, je ne sais pas, mais tout remettre a sa sauce en creant un nouveau projet... oui. Ce qui est tres important pour un systeme d'exploitation c'est la coherence, qu'est ce qui va se passer si par exemple, qq'un decide de faire evoluer une librairie, et l'integre dans un B.E.OS like compatible a 99% ? AMHA, un bordel a court terme et un desinteret des utilisateurs qui ne vont plus s'y retrouver dans les versions...
Je me souviens tres bien des discussions que nous avons pu avoir en interne au sujet de ce que vous avez vu sur la partie1 de la demo, cad le systeme de fenetrage. Cette approche a ete critiqué largement, personne n'a ete capable de demontrer que son approche etait meilleure... au lieu de commencer a coder d'autres approches, 2 nouveaux projets sont apparus: SequelOS et LeonadoOS...
Pourtant ces 2 coders sont des pointures, loin d'etre immatures..
[^] # Re: La
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Le CD de démo de BluEyedOS est disponible. Évalué à 9.
pas essayé perso, mais il parrait qu'à part jouer à BePuyo et écouter 5038 (l'hymne BeOSien) il fait pas grand chose le CD.
Effectivement, vu de l'exterieur ca peut parraitre 'pas grand chose' et pourtant!
Reprenons ce qu'il contient:
. 'kernel_server', un server qui mappe plus ou moins directement les APIs kernel de BeOS vers du linux.
Si vous faites des tests de perfs entre BeOS et B.E.OS, vous allez etre surpris tant BeOS est a la traine.
. 'app_server', encore un serveur! Il gere de facon multithreadé (exactement comme le fait BeOS) l'affichage et la gestion des evenements (il y a 1 thread par fenetre cote userland et 1 autre cote app_server).
Le reste a peu d'importance, juste la pour la demo, comme le systeme de fenetrage (part1) balaye tout ce qu'on peut voir sous linux en terme de fluidite. (si l'autoconf a bien fait son travail en trouvant le bon driver video)
Moi j'ai essayé mais mon affichage était brouillé
Soit ta carte ne supporte pas le 24/32bits ou l'autoconfig n'a pas ete en mesure de trouver le bon driver.
Apparemment ils ont peur d'un fork c'est pourquoi ils n'ont pas pris la GPL ou LGPL.
Pas un fork en tant que tel, genre emacs/Xemacs, mais une evolution paralelle et inutile du projet. Genre les n logiciel IRC en version 0.2 qui on 90% de leur code basé sur un autre qui lui etait en version 0.5.2, bref un gros bordel comme le monde linux le connait.
Leur projet me parait tres interressant, le coté pragmatique de la chose me plait beaucoup, mais tant qu'il n'y aura pas de garantie que le code devienne ouvert, ça ne m'interesse pas.
Le code sera mis en license BSD si le projet stagne ou disparait. Pourquoi BSD? Simplement, parce que si cela arrive, c'est que l'on n'aura plus rien a faire de linux.
Des que l'OS sera utilisable, cad qu'il atteindra la version 1.0, le code sera ouvert.
Les forks existent, oui, mais il n'y en a pas toutes les 5 minutes.
Si on compte le nombre de mailers, de servers ftp, de logiciels irc, news etc... on doit
pas etre loin d'un projet paralelle toute les semaines.
B.E.OS , Lindows, Wine...
Si on avait voulu un genre de wrapper ou une sorte de toolkit, tout aurait ete mappé sur un QT ou GTK.
La ou B.E.OS differe c'est que le but est de faire un OS, pas une distribution 'BeOS compatible'.
Le systeme sera basé sur une 20ene de librairies maximum, et des applis 100% B.E.OS (ie n'utilisant que l'API B.E.OS). Aurevoir KDE, Gnome et tout ce petit monde d'applis mal foutues, qui entre autre ne sont pas capables d'avoir un fonctionnement ou un look homogene.
boot en 10s, etc...
Sur BeOS, l'affichage apparait en quelques secondes, mais il en faut encore quelques unes pour le reste des inits.
Rien n'empeche de faire pareil sous linux, je l'ai deja fait.
Sur ma machine le CD de demo prend 1 minute avant de faire apparaitre l'affiche graphique. Ce qui est deja tres rapide vu que le filesystem est compressé et tourne sur CD!
Sans compter, l'autoconfig qui prend les 3/4 du temps...
B+
Guillaume