[ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 :: Suivant ]
alternatif
Sur la première pas du wiki :
Nous sommes fier d'ouvrir ce site sur Linux pour aider les nouveaux développeurs sous cet OS alternatif a Microsoft Windows(c)
Heu dans l'embarqué, Windows c'est lui l'OS alternatif... Linux c'est plutôt une alternative a VXWorks et autre OS embarqués propriétaires.
une version Linux embarqué
Je comprend pas vraiment c'est le même kernel que sur ton PC, just recompilé différement (arch & pilotes)
[ Répondre ]
Re: liaison symétrique
Et la vidéo LVDS/DVI/HDMI c'est du différenciel aussi
[ Répondre ]
Re: Excellente initiative !
Du coup, il faut peut être changer le nom aussi, Mondial pour un événement en français, ca fait un peu présomptueu.
[ Répondre ]
Re: Pas mal...
l'objet de la news c'est pas non plus de troller sur java vs python, je vois bien ou tu veux en venir ;)
[ Répondre ]
Re: asyncweb & streaming
En regardant le code, lorsqu'un fichier est envoyé au client je vois que le fichier est chargé et wrappé dans un IoBuffer, du coup, si le fichier fait 10MB, tu alloue 10MB dans le heap.
response.setContent(IoBuffer.wrap(file.content()));
Pour l'upload pareil, à un moment Asyncweb va remplir le IoBuffer qui sert de content pour HttpRequest et donc manger un gros buffer de la taille du fichier.
Je préfère prévenir :) C'est un problème d'asyncweb que je pense essayer de résoudre avant décembre.
Sinon je vois que vous utilisez MINA-2.0.0M2, il y a une grosse régression au niveau des perfs (https://issues.apache.org/jira/browse/DIRMINA-609 ), je vous conseille de passer sur M3 avec le dernier snapshot d'asyncweb-common.
[ Répondre ]
Re: OSGi
La question c'était plutôt est-ce que votre classloader va merder complétement avec OSGi, je pense que le plus ismple pour moi c'est de le tester :)
[ Répondre ]
OSGi
petite question, vu que cela utilise un classloader spécial pour la compilation des sources a la volé en utilisant le compilo d'eclipse, est-ce que c'est donné pour fonctionner dans un environement OSGi ?
[ Répondre ]
asyncweb & streaming
Connaissant bien Asyncweb, j'imagine qu'une page est entièrement généré en mémoire puis envoyées d'une seul bloc (pas d'envoi par chunk). Donc la génération de contenu un peu gros (plusieurs méga) doit être problématique ? De même que l'upload de gros fichiers à partir de formulaires ? En tout cas si vous avez du feeback a faire remonter sur Asyncweb (même si vous n'utiliser que la partie codec http) n'hésitez pas :)
Sinon au sujet des templates, pourquoi groovy plutôt qu'un langage dédié template type velocity/freemarker ?
[ Répondre ]
Re: Et Speex ?
Vorbis ca reste toujours un bon gros codec qui bouffe du FPU et pas adapté a la VoIP mais plutôt aux stream de musique. Je vois mal vorbis marcher sur les platebande de Speex (et inversemment).
[ Répondre ]
Donation ASF
Lorsque l'on fait une donation à l'ASF elle dite "non orienté" en effet c'est l'ASF qui dispose de la donation comme elle veut. C'est une condition pour accepter la donation. Donc les 100000$ vont dans les caisses et c'est l'ASF qui décide quoi en faire et sur quels projets l'utiliser. Donc c'est plutôt une bonne nouvelle \o/
http://apache.org/foundation/contributing.html
[ Répondre ]
code
l'IHM est sympa, même si le thème swing par défaut fait ramer mon PC :)
Je viens de regarder le code sources. C'est un projet d'étude ? car c'est étrange d'avoir écris les nom des variables et les commentaires en français, ça limite le nombre de contributeurs potentiels.
Au niveau du réseau pourquoi n'avoir pas utilisé de bibliothèque comme Apache MINA, Grizzly ou xsocket, voir même NIO, a la place de l'obsolète java.net. Ajouter, une compression, le SSL, des blacklists, une répartition de charge sur plusieurs threads, des logs, un protocole p2p, va devoir être fait à la main alors que les lib existent.
En tout cas, bon courage pour la suite.
[ Répondre ]
Re: dommage
Pour avoir utilisé les deux :
- la rapidité de apt/dpkg à coté de yum et autres,
- la stabilité de la base de package debian qui se vautre quasiement jamais, alors qu'une base rpm explosé ça arrive.
Sinon ca joue pas énormément sur la qualité de la distro, ce qui fait la différence entre deux c'est surtout la qualité des packages, plutot que le système de package en lui même.
[ Répondre ]
Re: Troll subtil
RPM un bon choix ?? mouarf
[ Répondre ]
Re: XMPP
ouais mais c'est pas "in" comme XML
[ Répondre ]
Re: XMPP
Je suis d'accord, sur le coup on ne peut pas en vouloir à google. XMPP est vraiment trop verbeux pour de l'embarqué.
[ Répondre ]
Re: un bon editeur...
ben non Eclipse+CDT ça marche pour les trois.
[ Répondre ]
Re: Génération suffisante ?
il y a toute une tripotée de fichier .so dans les archives pour Linux, donc je suppose que c'est implémenté en appelant le code C++ et non en pur Java.
[ Répondre ]
Re: Ah java...
C'est peu être toi qui est dans un monde à part ? :o)
[ Répondre ]
[ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 :: Suivant ]



Re: alternatif
quand je parle de linux enmbarqué, c'est pour bien faire la difference entre un linux (kernel) avec un environnement graphique comme gnome et la version Linux Kernel seul sans interface graphique par exemple.
gnome dans le kernel.. attention au bloat ;)
[ Répondre ]