Le mail (tant SMTP que IMAP) se repose sur une représentation textuelle des dates, donc tu pourrais même théoriquement envoyer un e-mail daté de l'an 1, de l'ère préhistorique ou du cinquième millénaire sans émouvoir le protocole.
Après la question c'est plutôt de savoir comment les différents programmes en présence vont réagir à une date non représentable par un timestamp. Tout dépend de s'ils se préoccupent de la date en question et de la façon dont ils vont la représenter en interne.
Moui, après, les spécifications du matos ont suivi le passage vers les 64 bits, et le lien du journal semble indiquer qu'il n'y a pas vraiment de gain et qu'on met une tonne d'indirections dans tous les sens.
Oui, alors on peut déjà installer des programmes i386 avec un noyau x64. Je ne pense pas que le fait de gagner des clopinettes dans des cas très rares justifie le fait de maintenir une nouvelle infrastructure au sein du noyau et d'installer une troisième copie de tout le système.
Je peux voir l'intérêt théorique (se faire travailler les méninges sur quelque chose que personne d'autre n'a fait) mais pour qu'une infra se développe, soit maintenue et soit correctement supportée, il faut également qu'elle ait un intérêt pratique évident, ce qui aurait probablement été davantage le cas si l'infra x32 remplaçait "au vol" l'infra x86 en étant compatible avec les anciens programmes.
Je peux parfaitement comprendre qu'un programme compilé sur une archi i686 puisse toujours fonctionner si on rajoute des nouveaux registres, ils seront juste pas utilisés.
Par contre, si on change la taille du type time_t, on casse l'ABI et un programme compilé pour i686 (avec un time_t de 32 bits) ne pourra pas interragir avec une lib x32 (avec un time_t de 64 bits) et inversement.
Donc, vous emballez pas les gars, x32 ne sera pas plus compatible avec x86 que x84 ne l'est, et cela ne vous permettra pas d'utiliser tout le potentiel de votre core 2 duo installé du temps où x64 était réservé aux téméraires sans le réinstaller...
Du coup l'intérêt est relativement limité. Tant qu'à réinstaller, autant réinstaller du x64 directement...
Autrement dit, ce que j'attendrais ce n'est pas une façon d'aller vers le haut de l'arborescence car on lit habituellement les réponses après avoir lu les questions.
Ce que j'attendrais, c'est une façon d'aller vers le bas.
Je ne sais pas trop pour les jeux, mais la plupart des programmes qui supportent de fonctionner en mode "pas installé" le font de la façon suivante:
D'abord tu as une fonction qui te retourne le chemin de base pour les données, qui en temps normal va retourner DATADIR "/monprog" (c'est toujours utile, et ça laisse le code propre)
Si tu buildes avec une option spécifique (genre --enable-uninstalled-build si je prends le cas de totem), alors la fonction est altérée pour aussi chercher dans . si ce n'est pas installé.
Alternativement tu peux te baser sur une variable d'environnement ou quelque chose du genre. Peut-être même que quand tu lances le programme sans l'installer il est en fait remplacé par un script shell qui exporte plein de trucs comme avec les autotools.
Ou alors tu t'en moques, et vu que de toute façon les données ne changent pas si souvent tu ne supportes pas le fait que ton programme soit lancé sans être installé. Si quelqu'un veut builder ton jeu sous windows par exemple, libre à lui de changer ton get_data_path() pour correspondre à ce qui est attendu par son système.
Oui, c'est vrai qu'on peut trouver le parent d'un commentaire précis, mais il reste quand même extrêmement difficile de pouvoir trouver les réponses directes à un commentaire donné quand on a des sujets trollifères qui s'épandent.
Cas classique, après cinq niveaux d'arborescence un mec commence à troller sur un détail sans intérêt, ce qui immanquablement génère 150 réactions. Il est extrêmement difficile en l'état d'ignorer totalement ce sous-thread, sauf en prenant une latte et en mesurant le nombre de centimètres entre le bord gauche de l'écran et le niveau de réponse désiré, et de scroller jusqu'à retrouver un commentaire du même niveau mesuré à la latte.
On a fait mieux à l'ère de l'informatique de masse, non ? ;-)
Avec les autotools ce genre de chose est triviale. La moindre des choses serait de pouvoir gérer un préfixe de compilation et aller y chercher les librairies (càd tester si libfoo.so existe et éventuellement s'il contient un symbole donné)
Ça serait cool de supporter CMAKE_INSTALL_PREFIX pour les gens qui veulent builder sans polluer leur /usr/local... Si j'en crois la doc avec cmake c'est utilisé tout seul si tu utilises les macros FIND_*()
Tu peux aussi avoir plusieurs threads: un pour la GUI et d'autres pour le reste. Tu peux même avoir plusieurs process pour être sûr, mais c'est peut-être plus chiant à gérer.
En effet, j'ai eu un Samsung Q1 dans les mains il y a quelques années (en 2007 ou 2008). Et bien le concept niveau hardware est exactement le même que l'iPad, avec intel qui bossait déjà sur une inclusion de moblin/maemo sur ce qu'ils appelaient à l'époque des MID (aka mobile internet devices)...
Bref, Apple n'a rien inventé, tout au plus ont-ils été capables de sortir un bon produit au bon moment et avec un price tag raisonnable.
la vue en thread oui: la liste des mails est affichée avec une arborescence, mais il faut cliquer sur chaque message pour l'afficher. Probablement tous les lecteurs font ca aujourd'hui non ?
Ben quand tu charges un module dynamique, c'est ld-linux.so qui s'occupe de tout linker. C'est du linkage tout beau comme sorti de gcc, tout comme quand tu utilises n'importe quel .so.
Si tu pouvais faire du proprio sous prétexte que tu as un .so et du linkage dynamique, tu viendrais de prouver que la GPL est caduque pour tout le contenu de /usr/lib. J'ose espérer que RMS y a pensé avant.
Pourquoi n'est il pas possible de faire la même chose via des appelles de fonctions ?
Ben une IPC ça peut être du RPC hein. Ceci dit c'est très borderline et je ne suis pas certain que tu puisses réellement faire ça.
Je suis bloqué entre deux licences contaminantes, l'une libre et l'autre propriétaire.
Non, on ne peut pas avoir de greffons non-GPL, vu qu'un plugin va toujours llnker avec le programme principal. Tu peux avoir une exception dans la licence de ton programme et des libs qu'il utilise mais ça implique que tu ne peux pas utiliser la moindre librairie GPL sans exception à partir de ce moment, du fait de la viralité de la GPL. Ce cas est illustré par exemple par Totem ou Rhythmbox, qui contiennent une exception pour pouvoir utiliser les plugins GStreamer de fluendo pour les formats brevetés. GStreamer lui-même est LGPL.
Par contre des gens mal (ou moins mal) intentionnés contournent régulièrement cela en travaillant avec des IPC, style client-serveur. Tu as un petit greffon en GPL qui implémente ton IPC et gère le processus proprio et tu attaques cet IPC depuis ton bout de programme proprio. Après est-ce que c'est légal ou non? J'imagine que c'est une question d'interprétation.
Ben le concept de gnome, c'est généralement que le mainteneur est seul maître à bord pour son projet, et mccann est le mainteneur (avec owen) de gnome-shell. Donc bon, voilà. Ça a des bons et des moins bons côtés.
Un simple retour à la ligne suffit, il y avait une entrée dans le suivi à ce propos. Râler à ce sujet prouve tout simplement que l'on n'a même pas essayé mais qu'on a râlé comme la masse qui râlait à la sortie du nouveau dlfp.
Posté par nud .
En réponse au journal Cream-Browser.
Évalué à 5.
Dans l'idée, ça me rappelle un peu uzbl, le côté script poilu en moins.
Sinon, tu as pensé à regarder du côté de libpeas pour les fonctions "sympas mais qui donnent les fesses lourdes" (aka plugins) à activer par l'utilisateur s'il trouve ça bien ?
Manque de documentation, brevets, chiffrement, licence d'utilisation restrictive des clients et serveurs disponibles, etc.
Quand il n'y a que la rétro-ingénierie qui te permet d'étudier et de comprendre le protocole, alors que la licence d'utilisation desdits clients/serveurs t'interdit explicitement de le faire et que certains pays interdisent la rétro-ingénierie, et qu'en plus le protocole est bardé de brevets logiciels, c'est un bon critère pour dire que le protocole est proprio.
[^] # Re: J'approuve
Posté par nud . En réponse au journal x32: Une nouvelle ABI Linux '32 bits' pour les CPU x86-64. Évalué à 2.
Le mail (tant SMTP que IMAP) se repose sur une représentation textuelle des dates, donc tu pourrais même théoriquement envoyer un e-mail daté de l'an 1, de l'ère préhistorique ou du cinquième millénaire sans émouvoir le protocole.
Après la question c'est plutôt de savoir comment les différents programmes en présence vont réagir à une date non représentable par un timestamp. Tout dépend de s'ils se préoccupent de la date en question et de la façon dont ils vont la représenter en interne.
[^] # Re: ABI 32 bits et time_t
Posté par nud . En réponse au journal x32: Une nouvelle ABI Linux '32 bits' pour les CPU x86-64. Évalué à 1.
Moui, après, les spécifications du matos ont suivi le passage vers les 64 bits, et le lien du journal semble indiquer qu'il n'y a pas vraiment de gain et qu'on met une tonne d'indirections dans tous les sens.
[^] # Re: ABI 32 bits et time_t
Posté par nud . En réponse au journal x32: Une nouvelle ABI Linux '32 bits' pour les CPU x86-64. Évalué à 2.
Oui, alors on peut déjà installer des programmes i386 avec un noyau x64. Je ne pense pas que le fait de gagner des clopinettes dans des cas très rares justifie le fait de maintenir une nouvelle infrastructure au sein du noyau et d'installer une troisième copie de tout le système.
Je peux voir l'intérêt théorique (se faire travailler les méninges sur quelque chose que personne d'autre n'a fait) mais pour qu'une infra se développe, soit maintenue et soit correctement supportée, il faut également qu'elle ait un intérêt pratique évident, ce qui aurait probablement été davantage le cas si l'infra x32 remplaçait "au vol" l'infra x86 en étant compatible avec les anciens programmes.
# ABI 32 bits et time_t
Posté par nud . En réponse au journal x32: Une nouvelle ABI Linux '32 bits' pour les CPU x86-64. Évalué à 3.
Je peux parfaitement comprendre qu'un programme compilé sur une archi i686 puisse toujours fonctionner si on rajoute des nouveaux registres, ils seront juste pas utilisés.
Par contre, si on change la taille du type time_t, on casse l'ABI et un programme compilé pour i686 (avec un time_t de 32 bits) ne pourra pas interragir avec une lib x32 (avec un time_t de 64 bits) et inversement.
Donc, vous emballez pas les gars, x32 ne sera pas plus compatible avec x86 que x84 ne l'est, et cela ne vous permettra pas d'utiliser tout le potentiel de votre core 2 duo installé du temps où x64 était réservé aux téméraires sans le réinstaller...
Du coup l'intérêt est relativement limité. Tant qu'à réinstaller, autant réinstaller du x64 directement...
[^] # Re: Ça existe en partie
Posté par nud . En réponse à l’entrée du suivi Difficile de visualiser l'arborescence des commentaires. Évalué à 1 (+0/-0).
Autrement dit, ce que j'attendrais ce n'est pas une façon d'aller vers le haut de l'arborescence car on lit habituellement les réponses après avoir lu les questions.
Ce que j'attendrais, c'est une façon d'aller vers le bas.
[^] # Re: Hum...
Posté par nud . En réponse à l’entrée du suivi Feed Atom pour le tableau de bord. Évalué à 1 (+0/-0).
Déjà ça permettrait de savoir que quelqu'un a répondu à l'un de ses commentaires ou à l'une de ses entrées de suivi.
# La foire au hack
Posté par nud . En réponse au message Savoir où chercher les données utilisées après un make install. Évalué à 1.
Je ne sais pas trop pour les jeux, mais la plupart des programmes qui supportent de fonctionner en mode "pas installé" le font de la façon suivante:
D'abord tu as une fonction qui te retourne le chemin de base pour les données, qui en temps normal va retourner DATADIR "/monprog" (c'est toujours utile, et ça laisse le code propre)
Si tu buildes avec une option spécifique (genre --enable-uninstalled-build si je prends le cas de totem), alors la fonction est altérée pour aussi chercher dans . si ce n'est pas installé.
Alternativement tu peux te baser sur une variable d'environnement ou quelque chose du genre. Peut-être même que quand tu lances le programme sans l'installer il est en fait remplacé par un script shell qui exporte plein de trucs comme avec les autotools.
Ou alors tu t'en moques, et vu que de toute façon les données ne changent pas si souvent tu ne supportes pas le fait que ton programme soit lancé sans être installé. Si quelqu'un veut builder ton jeu sous windows par exemple, libre à lui de changer ton get_data_path() pour correspondre à ce qui est attendu par son système.
[^] # Re: Ça existe en partie
Posté par nud . En réponse à l’entrée du suivi Difficile de visualiser l'arborescence des commentaires. Évalué à 1 (+0/-0).
Oui, c'est vrai qu'on peut trouver le parent d'un commentaire précis, mais il reste quand même extrêmement difficile de pouvoir trouver les réponses directes à un commentaire donné quand on a des sujets trollifères qui s'épandent.
Cas classique, après cinq niveaux d'arborescence un mec commence à troller sur un détail sans intérêt, ce qui immanquablement génère 150 réactions. Il est extrêmement difficile en l'état d'ignorer totalement ce sous-thread, sauf en prenant une latte et en mesurant le nombre de centimètres entre le bord gauche de l'écran et le niveau de réponse désiré, et de scroller jusqu'à retrouver un commentaire du même niveau mesuré à la latte.
On a fait mieux à l'ère de l'informatique de masse, non ? ;-)
[^] # Re: préfixe de compilation
Posté par nud . En réponse à la dépêche GeneticInvasion : des algorithmes évolutionnaires pour un meilleur jeu. Évalué à 1.
Il n'y a pas d'équivalent à AC_CHECK_LIBRARY?
Avec les autotools ce genre de chose est triviale. La moindre des choses serait de pouvoir gérer un préfixe de compilation et aller y chercher les librairies (càd tester si libfoo.so existe et éventuellement s'il contient un symbole donné)
[^] # Re: Nouveautés ?
Posté par nud . En réponse à la dépêche Thunderbird 5 est sorti. Évalué à 1.
Ah, je sais pas, je n'ai jamais encore vu d'outlook 2010 chez mes clients. Seulement du 2007...
[^] # Re: préfixe de compilation
Posté par nud . En réponse à la dépêche GeneticInvasion : des algorithmes évolutionnaires pour un meilleur jeu. Évalué à 1.
JE suis une quiche en cmake, mais j'ai dû ajouter les lignes suivantes pour que cela fonctionne:
Évidemment c'est tout pourri. Ou alors j'ai foiré quelque chose?
Ceci dit, sympa le jeu, même si ça a tendance à faire crasher nouveau.
# préfixe de compilation
Posté par nud . En réponse à la dépêche GeneticInvasion : des algorithmes évolutionnaires pour un meilleur jeu. Évalué à 1.
Ça serait cool de supporter CMAKE_INSTALL_PREFIX pour les gens qui veulent builder sans polluer leur /usr/local... Si j'en crois la doc avec cmake c'est utilisé tout seul si tu utilises les macros FIND_*()
[^] # Re: Exemple concret de line(1)
Posté par nud . En réponse au journal Line meurt. Évalué à 1.
Pour ce genre d'usage il vaut mieux utiliser read...
Ça permet de diminuer le nombre de processes à forker, donc c'est plus rapide, efficace, bref, plus mieux.
[^] # Re: Commentaire pinailleur sur les unités
Posté par nud . En réponse au journal Trucs pour consommer moins et éteindre plus sur Intel. Évalué à 2.
Et la puissance est la mesure de l'énergie produite/consommée/transformée dans une période donnée...
[^] # Re: Il y a bien longtemps...
Posté par nud . En réponse au journal Une info sur KDE on Wayland. Évalué à 2.
Tu peux aussi avoir plusieurs threads: un pour la GUI et d'autres pour le reste. Tu peux même avoir plusieurs process pour être sûr, mais c'est peut-être plus chiant à gérer.
[^] # Re: Décorations côté client
Posté par nud . En réponse au journal Une info sur KDE on Wayland. Évalué à 4.
Tu peux déjà faire une fenêtre transparente qui couvre tout l'écran avec X11, et tu peux observer pas mal de choses même sans avoir de fenêtre...
# Samsung devrait porter plainte également
Posté par nud . En réponse au journal Pomme, rectangle robots.... Évalué à 6.
Moi je trouve que Samsung devrait porter plainte.
En effet, j'ai eu un Samsung Q1 dans les mains il y a quelques années (en 2007 ou 2008). Et bien le concept niveau hardware est exactement le même que l'iPad, avec intel qui bossait déjà sur une inclusion de moblin/maemo sur ce qu'ils appelaient à l'époque des MID (aka mobile internet devices)...
Bref, Apple n'a rien inventé, tout au plus ont-ils été capables de sortir un bon produit au bon moment et avec un price tag raisonnable.
[^] # Re: Modestie...
Posté par nud . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 3.
Non, j'ai toujours utilisé gnome (même 3.0) et je n'ai jamais utilisé pulseaudio.
[^] # Re: Nouveautés ?
Posté par nud . En réponse à la dépêche Thunderbird 5 est sorti. Évalué à 1.
Pas Outlook...
[^] # Re: Greffons non-GPL
Posté par nud . En réponse au message licence GPL et greffon chargé dynamiquement. Évalué à 1.
Ben quand tu charges un module dynamique, c'est ld-linux.so qui s'occupe de tout linker. C'est du linkage tout beau comme sorti de gcc, tout comme quand tu utilises n'importe quel .so.
Si tu pouvais faire du proprio sous prétexte que tu as un .so et du linkage dynamique, tu viendrais de prouver que la GPL est caduque pour tout le contenu de /usr/lib. J'ose espérer que RMS y a pensé avant.
Ben une IPC ça peut être du RPC hein. Ceci dit c'est très borderline et je ne suis pas certain que tu puisses réellement faire ça.
Ben utilise autre chose ou réécrit l'un des deux.
[^] # Greffons non-GPL
Posté par nud . En réponse au message licence GPL et greffon chargé dynamiquement. Évalué à 2.
Non, on ne peut pas avoir de greffons non-GPL, vu qu'un plugin va toujours llnker avec le programme principal. Tu peux avoir une exception dans la licence de ton programme et des libs qu'il utilise mais ça implique que tu ne peux pas utiliser la moindre librairie GPL sans exception à partir de ce moment, du fait de la viralité de la GPL. Ce cas est illustré par exemple par Totem ou Rhythmbox, qui contiennent une exception pour pouvoir utiliser les plugins GStreamer de fluendo pour les formats brevetés. GStreamer lui-même est LGPL.
Par contre des gens mal (ou moins mal) intentionnés contournent régulièrement cela en travaillant avec des IPC, style client-serveur. Tu as un petit greffon en GPL qui implémente ton IPC et gère le processus proprio et tu attaques cet IPC depuis ton bout de programme proprio. Après est-ce que c'est légal ou non? J'imagine que c'est une question d'interprétation.
Disclaimer: IANAL.
[^] # Re: Pas mal... Mais pas extra
Posté par nud . En réponse au sondage Le nouveau gnome-shell.... Évalué à 6.
Ben le concept de gnome, c'est généralement que le mainteneur est seul maître à bord pour son projet, et mccann est le mainteneur (avec owen) de gnome-shell. Donc bon, voilà. Ça a des bons et des moins bons côtés.
[^] # Re: Grosse déception
Posté par nud . En réponse à la dépêche GNOME 3.0 : le grand saut !. Évalué à -1.
Ce n'est
même pas
nécessaire
Un simple retour à la ligne suffit, il y avait une entrée dans le suivi à ce propos. Râler à ce sujet prouve tout simplement que l'on n'a même pas essayé mais qu'on a râlé comme la masse qui râlait à la sortie du nouveau dlfp.
# uzbl
Posté par nud . En réponse au journal Cream-Browser. Évalué à 5.
Dans l'idée, ça me rappelle un peu uzbl, le côté script poilu en moins.
Sinon, tu as pensé à regarder du côté de libpeas pour les fonctions "sympas mais qui donnent les fesses lourdes" (aka plugins) à activer par l'utilisateur s'il trouve ça bien ?
[^] # Re: Plusieurs questions et remarques
Posté par nud . En réponse à la dépêche Effervescence autour de la pile graphique libre. Évalué à 3.
Manque de documentation, brevets, chiffrement, licence d'utilisation restrictive des clients et serveurs disponibles, etc.
Quand il n'y a que la rétro-ingénierie qui te permet d'étudier et de comprendre le protocole, alors que la licence d'utilisation desdits clients/serveurs t'interdit explicitement de le faire et que certains pays interdisent la rétro-ingénierie, et qu'en plus le protocole est bardé de brevets logiciels, c'est un bon critère pour dire que le protocole est proprio.