Sait on sur quel version il sera compatible.
A ma connaissance le NDK android permet d'avoir des appli purement native qu'a partir de froyo. Avant il fallait forcement avoir un bout en java.
Un truc marrant que je souhaiterais faire, mais je sais pas si je trouverais le temps :
a partir des horaires en temps reel donnée sur le site de la ratp (prochain train a une station), sur une ligne en prenant quelques stations clef, récupérer l'horaire réel de départ de chaque train
faire des stats avec l'horaire officiel. Genre en heure de pointe x% de train sont plus de 5% de retard.
analyser les décisions de régulation des trains.
faire une appli qui rejout le traffic de la journée.
[...]
Pour le rer, la récupération des donnée ne pose pas de pb. Par contre ce qui est chiant c'est que les trains ne sont pas numérotés (On a juste la mission). Du coup à moins de poller en permanence le site de la ratp, il faut trouver un algo malin qui identifie les trains, retrouve le train dans les horaires d'une station et détecte les trains qui se double, les trains supprimé, les trains qui prenne du retard, ...
Pour le metro ça doit être pire, c'est tous la même mission, par contre il ne se double pas.
Si à la place de chaque onglet de chaque application c'est une instance séparée qui est créée, tu peux acheter quelques barrettes de RAM je pense…
Pas forcement : l'application ne gére plus les onglet. Elle est plus légère. Et comme l'OS est malin il partage la plupart des données des 2 instances avec le COW.
Alors que faire ? Doit-on choisir de se limiter à POSIX ou bien ne coder que pour Linux en se disant que les autres suivront ?
Ben le mieux c'est de faire le maximun en POSIX et puis utilisé des API linux pour les trucs qui n'existe pas dans POSIX (udev, ...).
Mais faire un soft POSIX portable n'est pas simple si on a pas plusieurs plateformes pour tester. Les specs sont parfois ambiguë, et chaque OS prendre quelque fois des libertés (et même sur un même OS ca peut varier entre les libc : glibc, uclibc, bionic, ...). Mais ca restera plus simple à porter que un truc coder uniquement pour Linux.
Après ça dépend quel est la porté de ton projet. C'est sur que si tu code un truc spécifique linux, autant se faire plaisir.
Lennart est dans son droit d'écrire son code comme il le veut.
Là ou c'est plus tangent c'est quand il recommande joyeusement aux autres de faire comme lui:
Mouais, c'est son choix. Le mien c'est de faire profiter mon soft au maximun de gens quelque soit la plateforme qu'ils utilisent.
Sauf qu'avant au pire pour accéder a des fonctionnalité avancé il fallait flash, maintenant il va falloir :
- un navigateur a jour (exit les vieux navigateur)
- un navigateur qui supporte les bon codecs
- un os qui supporte correctement opengl
[...]
Si les webmaster ne prévoit pas un mode de rétro compatibilité [1], on risque de ce retrouver avec un web de moins en moins portable (et tout ca pour des fonctionnalités parfois bien discutable) .
[1] on me souffle a l'oreille que la nouvelle version de linuxfr RoR en html5 ne fonctionne pas avec les broswer un peu vieux.
Ce qui signifie que d'ici à très peu d'années, on ne rencontrera sans doute plus d'ordinateurs sans carte 3D basique,
C'est bien beau d'avoir une carte 3D, mais sans driver c'est la même chose qu'une carte pas 3D...
Et quand je vois le mal que les dev ont pour supporter la 3D sur une génération donnée, je me dis que c'est pas gagné.
Et les pilotes proprio ne maintienne pas le vieux matos
Ça m'a sidéré qu'un truc récent comme CMake n'était pas capable de gérer correctement par défaut les compilations statiques/dynamiques (la liste de lib est la même dans les deux cas !).
C'est clair que moi aussi j'ai été dessus par CMake.
Des que tu veux faire un truc un peu complexe on peut tomber sur un cratère (ie c'est pas possible).
Quand aux autotools c'est une utsine a gaz qui produit des trucs imbitable. Leur configure pour des raison de portabilité est très moche.
Les Makefile générer ne sont pas mieux.
Et pour couronner le tout plein de gens font des trucs louche avec autotools.
C'est bien ce que je dis chacun est obligé de refaire un truc a sa sauce avec les pbs que ca comporte (maintenance, pour chaque système il faut apprendre comme il fonctionne, ...).
Je vois mal comment cela pourrait être générique, cela démontre plustôt la souplesse de make;
Certes mais tout les projets ne veulent/peuvent pas avoir des experts make dans leur équipes.
Compte le nombre de gens qui connaisse bien les templates que tu as cité (ie seront corrigé un bug dedans, ajouter des nouvelles fonctionnalitées).
il y moyen de faire de trucs propre, aussi ;) .
Comme dans a peu pres tout les langages.
Oui je connais les templates makefile qui simplifie la vie.
Mais pour en avoir fait une au boulot (pour un projet de plusieurs milliers de fichiers) et ben je regrette de n'avoir pas pu utiliser une autre option a l'époque.
Le code de la template est plein de magic make incompréhensible. Des qu'il faut modifier le comportement, c'est la galère. Ca devient un truc pas maintenable, compris par quelques gurus.
On ne fait pas de make recursif, chaque sous projet inclue ses makefiles (avec la commande include de make). Et ben une boulette dans un sous makefile peu faire tout péter sans moyen simple de le debugger.
Les gens développant les sous projet ne sont pas familier avec make et font vite des boulettes qui fait tout planter.
Bref make c'est simple sur des petits projets. Mais sur des gros projets ou il faut gérer différentes versions de build (dans des répertoires différent), de la compilation conditionnelle, des tests dynamiques, ..., on arrive vite a devoir réinventer la roue et obtenir un truc bancale.
Et d'ailleurs il n'y a pas de solution de template makefile générique. La plus évolué étant le système du kernel Linux.
Je pense pas que make soit un pb, il fait ce pourquoi il a été conçu : gestion de dépendance. Par contre sont gros problème c'est pour debugger des makefile.
Le pb c'est que les gens veule un truc plus haut niveau : filer une liste de fichiers a compiler, des options de génération (compil/link) et éventuellement faire des test dynamique sur les dépendance (version des lib, support de tel fonction, ...). Et aussi avoir une GUI a la kconfig, pour permettre de sélectionner des options de config.
C'est ce que font les autotools, mais franchement je trouve qu'ils sont une usine a gaz (makefile générer inbitable, pb de cross compilation, trop complex (les devs ne comprenne pas forcement ce qu'ils font)). Je ne parle même pas du libtool qui vient avec.
Il y a cmake, mais la derniére fois que j'ai regardé ca ma pas convaincu.
Il y a du code qui traine pour les plateforme nvidia tegra2. Par contre la dernière fois que j'ai regardé c'était assez crade et il devait manquer des bouts (gpu).
En fait armv5 et - ont des pb des contextes switch : pour des questions de couts, le cache est indexé virtuellement, du coup dès que l'on change de contexte, il faut tout flusher.
Mais sur les archis récentes (armv6, cortex), il n'y a plus de soucis.
A ce prix la, ne vaut il pas mieux ce prendre une formule internet only (neuf en a une a 15 €) et avec les 15€ qui reste trouver un provider SIP externe qui fait des offres correctes ?
Pour connecter le téléphone il existe des boitiers ethernet/SIP vers fxs (prise téléphone) qui devrait être vite rentabilisé...
Une dizaine de bornes avec leurs clients, qui passent leur temps à transmettre des demandes d'émission (RTS, ready to send), s'apercevoir que quelqu'un d'autre a envoyé une demande en même temps sur le même canal pour un autre réseau, voire pour le même, attendre un peu, renvoyer une demande, la borne envoyant une autorisation d'émettre (CTS, clearance to send), s'apercevant qu'une autre borne en a envoyé une autre aussi, attendre un peu, recommencer, le client recevant l'autorisation et commençant à transmettre, bloquant les transmissions sur ce canal pendant ce temps, et ainsi de suite.
En fait si tout le monde est sur le même canal ca marche pas trop mal : tout le monde voit les RTS et CTS circuler.
La ou ca ce corse c'est quand on est sur des canaux voisins : on arrive plus a décoder le flux et donc a plus concience des RTS/CTS des autres (on sait pas quand ils émettent). On a seulement des paquets corrompu en permanence.
[^] # Re: Doublon
Posté par M . En réponse à l’entrée du suivi voir à quoi on répond. Évalué à 2 (+0/-0).
autant pour moi, y a pas moyen de fermer se bug (et de reporter les votes dans l'autres) ?
A ma décharge,la recherche des suivis déjà existant n'est pas triviale (a part lire tout les bugs).
[^] # Re: ...
Posté par M . En réponse au journal La RATP veux faire taire incidents-ratp.com. Évalué à 2.
C'est quoi le rapport avec la choucroute ?
# version
Posté par M . En réponse au journal Qt pour Android en version alpha. Évalué à 5.
Sait on sur quel version il sera compatible. A ma connaissance le NDK android permet d'avoir des appli purement native qu'a partir de froyo. Avant il fallait forcement avoir un bout en java.
Sinon il y a sdl qui tourne sur android et qui permet de faire des trucs simple : https://github.com/pelya/commandergenius
[^] # Re: Je plussoie
Posté par M . En réponse à l’entrée du suivi Cacher les avatars et certains formatages. Évalué à 5 (+0/-0).
idem, les images pouvant être insérer dans les journaux/commentaires sont aussi une nuisance visuel. Il faudrait pouvoir les désactiver
# ...
Posté par M . En réponse à l’entrée du suivi Plus de CSS par session. Évalué à 4 (+0/-0).
Il me semble qu'en plus avant on pouvait avoir une css perso, même si on était pas loggé.
# ...
Posté par M . En réponse au journal La RATP veux faire taire incidents-ratp.com. Évalué à 3.
Un truc marrant que je souhaiterais faire, mais je sais pas si je trouverais le temps :
Pour le rer, la récupération des donnée ne pose pas de pb. Par contre ce qui est chiant c'est que les trains ne sont pas numérotés (On a juste la mission). Du coup à moins de poller en permanence le site de la ratp, il faut trouver un algo malin qui identifie les trains, retrouve le train dans les horaires d'une station et détecte les trains qui se double, les trains supprimé, les trains qui prenne du retard, ...
Pour le metro ça doit être pire, c'est tous la même mission, par contre il ne se double pas.
# ...
Posté par M . En réponse à la dépêche Nouvelle version de LinuxFr.org. Évalué à 2.
C'est normal que quand on est pas logué on ne voit pas tout les commentaires ?
# ada
Posté par M . En réponse au journal the Ada Initiative. Évalué à 10.
# .
Posté par M . En réponse à la dépêche Des nouvelles de Linphone (VoIP). Évalué à 2.
Pas mal de hard ont un accéléreration hardware
La nouvelle api de androïd propose une stack sip. De multiples clients sip devrait voir le jour
[^] # Re: Questions
Posté par M . En réponse à la dépêche Sortie officielle de GTK+ 3.0 !. Évalué à 4.
Pas forcement : l'application ne gére plus les onglet. Elle est plus légère. Et comme l'OS est malin il partage la plupart des données des 2 instances avec le COW.
# symbian
Posté par M . En réponse à la dépêche Windows Phone 7 débarquera sur les Nokia. Évalué à 2.
Je suppose que pour l'entré/milieu de gamme rien ne va changer. Donc symbian devrait perdurer sur les milieu de gamme.
Ou alors nokia va arrêter cette gamme de produit ?
[^] # Re: ben il te propose une offre ADSL
Posté par M . En réponse au journal adsl ovh. Évalué à 6.
Oui mais si tu économises 10€ par mois, ca va être vite rentable.
free font pareil avec alice...
# posix + linux
Posté par M . En réponse au journal Linux ou POSIX ?. Évalué à 6.
Ben le mieux c'est de faire le maximun en POSIX et puis utilisé des API linux pour les trucs qui n'existe pas dans POSIX (udev, ...).
Mais faire un soft POSIX portable n'est pas simple si on a pas plusieurs plateformes pour tester. Les specs sont parfois ambiguë, et chaque OS prendre quelque fois des libertés (et même sur un même OS ca peut varier entre les libc : glibc, uclibc, bionic, ...). Mais ca restera plus simple à porter que un truc coder uniquement pour Linux.
Après ça dépend quel est la porté de ton projet. C'est sur que si tu code un truc spécifique linux, autant se faire plaisir.
Lennart est dans son droit d'écrire son code comme il le veut.
Là ou c'est plus tangent c'est quand il recommande joyeusement aux autres de faire comme lui:
Mouais, c'est son choix. Le mien c'est de faire profiter mon soft au maximun de gens quelque soit la plateforme qu'ils utilisent.
# html5 & co
Posté par M . En réponse à la dépêche Firefox 4 et pilotes de cartes graphiques sous Linux. Évalué à 3.
Sauf qu'avant au pire pour accéder a des fonctionnalité avancé il fallait flash, maintenant il va falloir :
- un navigateur a jour (exit les vieux navigateur)
- un navigateur qui supporte les bon codecs
- un os qui supporte correctement opengl
[...]
Si les webmaster ne prévoit pas un mode de rétro compatibilité [1], on risque de ce retrouver avec un web de moins en moins portable (et tout ca pour des fonctionnalités parfois bien discutable) .
[1] on me souffle a l'oreille que la nouvelle version de linuxfr RoR en html5 ne fonctionne pas avec les broswer un peu vieux.
[^] # Re: Simplement tout faire par OpenGL
Posté par M . En réponse à la dépêche Firefox 4 et pilotes de cartes graphiques sous Linux. Évalué à 7.
C'est bien beau d'avoir une carte 3D, mais sans driver c'est la même chose qu'une carte pas 3D...
Et quand je vois le mal que les dev ont pour supporter la 3D sur une génération donnée, je me dis que c'est pas gagné.
Et les pilotes proprio ne maintienne pas le vieux matos
[^] # Re: CMake ?
Posté par M . En réponse à la dépêche Redo, un remplaçant de choix pour Make. Évalué à 2.
C'est clair que moi aussi j'ai été dessus par CMake.
Des que tu veux faire un truc un peu complexe on peut tomber sur un cratère (ie c'est pas possible).
Quand aux autotools c'est une utsine a gaz qui produit des trucs imbitable. Leur configure pour des raison de portabilité est très moche.
Les Makefile générer ne sont pas mieux.
Et pour couronner le tout plein de gens font des trucs louche avec autotools.
[^] # Re: make ?
Posté par M . En réponse à la dépêche Redo, un remplaçant de choix pour Make. Évalué à 2.
Je vois mal comment cela pourrait être générique, cela démontre plustôt la souplesse de make;
Certes mais tout les projets ne veulent/peuvent pas avoir des experts make dans leur équipes.
Compte le nombre de gens qui connaisse bien les templates que tu as cité (ie seront corrigé un bug dedans, ajouter des nouvelles fonctionnalitées).
il y moyen de faire de trucs propre, aussi ;) .
Comme dans a peu pres tout les langages.
[^] # Re: make ?
Posté par M . En réponse à la dépêche Redo, un remplaçant de choix pour Make. Évalué à 2.
Après s'ils sont passé par paramètre c'est la misère.
[^] # Re: make ?
Posté par M . En réponse à la dépêche Redo, un remplaçant de choix pour Make. Évalué à 2.
Mais pour en avoir fait une au boulot (pour un projet de plusieurs milliers de fichiers) et ben je regrette de n'avoir pas pu utiliser une autre option a l'époque.
Le code de la template est plein de magic make incompréhensible. Des qu'il faut modifier le comportement, c'est la galère. Ca devient un truc pas maintenable, compris par quelques gurus.
On ne fait pas de make recursif, chaque sous projet inclue ses makefiles (avec la commande include de make). Et ben une boulette dans un sous makefile peu faire tout péter sans moyen simple de le debugger.
Les gens développant les sous projet ne sont pas familier avec make et font vite des boulettes qui fait tout planter.
Bref make c'est simple sur des petits projets. Mais sur des gros projets ou il faut gérer différentes versions de build (dans des répertoires différent), de la compilation conditionnelle, des tests dynamiques, ..., on arrive vite a devoir réinventer la roue et obtenir un truc bancale.
Et d'ailleurs il n'y a pas de solution de template makefile générique. La plus évolué étant le système du kernel Linux.
# make ?
Posté par M . En réponse à la dépêche Redo, un remplaçant de choix pour Make. Évalué à 9.
Le pb c'est que les gens veule un truc plus haut niveau : filer une liste de fichiers a compiler, des options de génération (compil/link) et éventuellement faire des test dynamique sur les dépendance (version des lib, support de tel fonction, ...). Et aussi avoir une GUI a la kconfig, pour permettre de sélectionner des options de config.
C'est ce que font les autotools, mais franchement je trouve qu'ils sont une usine a gaz (makefile générer inbitable, pb de cross compilation, trop complex (les devs ne comprenne pas forcement ce qu'ils font)). Je ne parle même pas du libtool qui vient avec.
Il y a cmake, mais la derniére fois que j'ai regardé ca ma pas convaincu.
ps :
redo-ifchange $1.c
gcc -MD -MF $3.deps.tmp -c -o $3 $1.c
DEPS=$(sed -e "s/^$3://" -e 's/\\//g' <$3.deps.tmp)
rm -f $3.deps.tmp
redo-ifchange $DEPS
et ben ca m'a pas l'air très simple
[^] # Re: Proc != GPU
Posté par M . En réponse au journal Projet Denver de Nvidia. Évalué à 5.
Donc autour du cpu tu vas trouver tout un tas de composant ajouté (fait ou acheté) par nvidia qui ne seront pas standard (usb, serie, gpu, ...).
Du coup même si tu as les docs du cpu tu n'iras pas loin sans les docs de tous les composants autour.
[^] # Re: C'était prévisible...
Posté par M . En réponse au journal Projet Denver de Nvidia. Évalué à 2.
[^] # Re: Reste à attendre…
Posté par M . En réponse au journal Projet Denver de Nvidia. Évalué à 3.
Mais sur les archis récentes (armv6, cortex), il n'y a plus de soucis.
# SIP alternatif
Posté par M . En réponse au journal Free réinvente le « double play » et casse le tarif unique. Évalué à 3.
Pour connecter le téléphone il existe des boitiers ethernet/SIP vers fxs (prise téléphone) qui devrait être vite rentabilisé...
[^] # Re: Débit wifi
Posté par M . En réponse au journal Il a Orange et il est Vert. Évalué à 3.
En fait si tout le monde est sur le même canal ca marche pas trop mal : tout le monde voit les RTS et CTS circuler.
La ou ca ce corse c'est quand on est sur des canaux voisins : on arrive plus a décoder le flux et donc a plus concience des RTS/CTS des autres (on sait pas quand ils émettent). On a seulement des paquets corrompu en permanence.