Ah merci, je ne savais pas…
Mais du coup, il y a un bug d'intégration avec LXDE puisque le réglage "ne pas lancer l'hibernation quand on ferme l'écran" ne fonctionne pas et oblige à aller changer le fichier de conf.
Quand à systemd-udevd, c'est ce bon vieux udev qui remplace devfs depuis bientôt une bonne dizaine d'années.
Oui évidemment ! (pour le coup ce n'était pas là la question. J'étais juste surpris que Canonical se base sur la version mergée avec systemd)
Bon après, Debian a choisi systemd comme init par défaut. ça ne veut pas dire que c'est le seul. Canonical aurait pu choisir de continuer à supporter un autre init.
N.B. sur une LUbuntu 13.10 récemment installée au bureau, j'ai observé que le réglage "ne pas mettre en veille lors de la fermeture de l'écran" était ignoré par la machine, et qu'il fallait que j'aille trifouiller /etc/systemd/logind.conf pour paramétrer "HandleLidSwitch=ignore" pour que ça (re)marche. Il s'agit d'une installation LUbuntu 13.10 de base sur un PC Dell D410 => qqun sait me dire ce que systemd/logind fait ici alors que je n'ai rien demandé ? (ps ax renvoie systemd-logind et systemd-udevd)
<troll>Personnellement j'aimais bien l'init de Pardus</troll>
j'ai du mal a accepter certaine chose. Ainsi l'hafnium est lie dans les mines au Zirconium, donc il me parait logique que tant qu'on mine du Zirconium, on mine en meme temps de l'hafnium.
Demande toi: l'hafnium est présent en quelle proportion dans le minerais ? Sa consommation évolue à quel rythme par rapport à l'ensemble du stock ?
Tout depend de ce que l'on cherche, mais certains asteroid contienne a eux seul plus par exemple de platine que ce que l'humanite a exploiter depuis qu'on exploite le platine. Les volumes ne sont clairement pas le probleme ici.
Sauf que nos soucis ne se limitent pas au platine (qui représente des faibles masses parmi tout ce qui est miné), mais plein d'autre chose aux ordres de grandeurs considérablement plus élevés. Tu vas faire quoi pour le zinc et le cuivre ?
Encore une fois: qu'on sache ramener 3 cailloux n'est pas le sujet (et si dans le cas du platine, ramener 3 cailloux résoud le souci, tant mieux. Mais j'en doute…)
Plus serieusement, la mecanique et la navigation spatiale, au vu des prouesses realises par nos sondes est quelques chose de bien maitrise… Une fois qu'on saura comment "pousser" un asteroid !
Il y a comme un léger décalage entre "plus sérieusement" et "une fois qu'on saura comment pousser un astéroïde" ! Non, ça n'est pas (et à mon avis ne sera jamais) faisable. Je pense que tu surestimes beaucoup le niveau technologique de notre espèce. L'homme n'est pas un dieu au dessus des lois de la physique ! Dans la vraie vie, ça ne marche pas comme dans star wars.
Euh, tu te contredis un peu. D'un cote tu dis que les objets celetes se baladent et de l'autre qu'il reste trop a proximite de la terre
Où ça ?
Hormis la lune et les satellites artificiels (+ leurs débris), il n'y a pas d'astéroïde en orbite stable autour de notre planète. Encore moins d'objet celeste exploitable sur le plan minier !
C'est effectivement un des challenge, mais je n'aurais pas mis celui la en premier. Il faut les cartographiers, reussir a "atterir" dessus, les decouper en petit morceaux et les traiter avant de les renvoyer la ou on en a besoin. Clairement des tres gros problemes d'ingenierie et il faut probablement compter en decennie avant de resoudre ces problemes. Mais le probleme des volumes n'est probablement pas le premier sur la liste.
Encore une fois: regarde combien d'énergie (et de matières) il faut pour satelliser un kg. Idem si tu veux imaginer de les "découper" (N.B. sans moteur thermique, puisqu'il n'y a pas d'oxygène, donc pas d'usage du pétrole hein :). De même pour ramener sur terre des volumes (donc des masses) élevées sans que ça se désintègre…
Je n'ai pas trouve d'info sur le sujet, tu aurais un lien ?
J'ai déjà mis ce lien dans mon post précédent plus haut.
Il devient donc logique de commencer a investir maintenant dans les technologies d'exploitation spatiale de ressource.
L'exploitation spatiale restera à mon avis à jamais de la science-fiction. Le fait que tu arrives éventuellement à ramener un jour 3 cailloux intacts d'un astéroïde ou planetoïde voisin ne veut pas dire
que ça passe à l'échelle sur le volume (c'est toute la différence entre le lab et l'échelle industrielle !)
que ça passe à l'échelle dans la durée (ben oui, tes objets celestes se baladent dans l'espace et ne vont pas rester bien sagement à proximité de notre bonne vieille terre. Accessoirement, on ne sait déjà pas nettoyer la poubelle spatiale qu'on est en train de créer…)
que tu ne consommes pas de ressources pour l'ensemble de l'activité "minière" elle-même (regarde combien d'énergie il faut pour satelliser 1kg…). C'est précisément un élément limitant pour le passage à l'échelle sur le volume.
Il n'y a pas d'alternative à la "chasse aux gaspis" !
C'est a dire que les ressources etant la, il n'y a rien qui semble bloquant pour arriver a un resultat
Bien sûr que si
evidemment ce sont des problèmes d'ingénierie, mais ça ne veut pas dire qu'il y a toujours une solution ! Evidemment, la marche semble moins haute que pour la fusion (qui ne donnera dans tous les cas rien d'ici 50-100 ans), mais attention à ne pas considérer le thorium comme un remède miracle.
le thorium lui-même est abondant, mais quid des autres éléments rares qui seront nécessaires pour que l'ensemble de l'édifice fonctionne ? (par exemple, les barres de MOX des centrales actuelles sont entourées de gaines de zirconium, dont les réserves au rythme actuel sont d'environ 40 ans)
Et donc justement: dès lors qu'il y a "architecture de shaders unifiés" (donc un HW 100% programmable), qu'est-ce qui s'oppose à ce que ça supporte les mêmes fonctionnalités que les générations suivantes ?
(je ne suis pas spécialiste => est-ce que OpenGL 4.0 ou OpenGL-ES 3.0 présument des fonctionnalités HW particulières qui seraient absentes des cartes OpenGL2.1 par exemple ?)
Mais ce que font les Chinois, c'est juste de constituer des stocks de Thorium et lancer en parallele la R&D necessaire a la production nucleaire en utilisant comme carburant le Thorium
Au fait, en complément de ma réponse précédente, j'ajouterais que même si une solution technique est trouvée pour rendre le thorium utilisable, cela ne préjuge pas de la faisabilité de son passage à l'échelle et de sa durabilité. Car même si le Thorium lui-même est abondant sur terre, ses dépendances pourraient être rares. Par exemple, le combustible MOX des centrales actuelles est entouré de gaines de Zirconium, dont les réserves sont estimées à 40 ans (au rythme actuel, donc sans prendre en compte un éventuel accroissement de la demande). Dans un système complexe comme une centrale au thorium, il est à craindre que certains éléments minéraux (autres que le thorium lui-même) deviennent un goulet d'étranglement. Mais personne ne semble en avoir conscience, la spécialisation à outrance dans notre société et notre mode de pensée présumant des ressources habituelles infinies fait qu'on manque de systémiciens et de personnes ayant une vision un peu globale.
Bref, considérer que le thorium est la solution-miracle à nos problèmes est encore très prématuré…
Si c'est une terre rare, alors c'est un faux probleme
1°/ Le hafnium ne fait pas parti des composés dits "terres rares" au sens chimique du terme. Et je n'ai pas inventé le fait que la plupart des gisements économiquement exploitables seraient épuisés vers 2018.
2°/ faux problème ? Comme toute ressource finie et non renouvelable, la production de terres rares atteindra un jour un pic inexorable !
3°/ Même dans le cas où les terres rares ne sont pas toujours "rares" dans la croûte (ça dépend des éléments chimiques), elles sont globalement très peu concentrées. Pour cela, leur exploitation est très polluante et aussi très énergivore. Or, on va aussi manquer d'énergie dans les années qui viennent…
4°/ La filière thorium n'est pas au point. Elle est présentée comme un remède miracle, mais pour l'instant des difficultés techniques restent encore non résolues (et par définition, on ne sait pas si/comment on pourra les résoudre !)
les puces Intel, par exemple, bénéficient de la prise en charge d’OpenGL ES à partir des CPU de génération Sandy Bridge, c-a-d à partir des puces graphiques Gen6 dans la nomenclature du fondeur)
Il y a une raison technique qui explique le non-support sur les générations précédentes ? Pour ma part, j'ai un core i5 M520 avec une puce graphique "gen5", que j'estime encore suffisamment récent pour ne pas justifier un changement de machine, et il me semblait que la gen5 disposait déjà d'un pipeline entièrement programmable (par opposition au pipeline fixe conçu pour OpenGL 1.x qui fait que les vieux laptops avec un GMA950 ne pourront jamais supporter les shaders). Accessoirement sur la page sandy bridge de wikipedia, on lit "utilisation d'hafnium comme isolant au sein des transistors des processeurs", sauf que "Les gisements exploitables de hafnium à un coût acceptable seront épuisés autour de 2018" donc ce serait bien de ne pas changer de machine tous les 3-4 matins…
"c'est quoi l'intérêt de supporter ça dans LibO" ? Eh bien, juste de pouvoir être compatible avec les documents des autres ! La compatibilité avec .docx reste incomplète sans ça…
"c'est quoi l'intérêt de faire ça" ? On est d'accord que c'est critiquable, mais bon, des gens l'utilisent et on ne peut rien y faire. En l'occurence ici il s'agit de la CEPT et des contributeurs/administrations associées. ça fait beaucoup de monde et je n'ai aucun moyen de pression pour faire changer les choses, d'autant que personne ne s'en plaint (à part moi) puisque tout le monde utilise MS Office et n'a aucun problème avec cette fonctionnalité (qui est d'ailleurs à leurs yeux plus simple que d'utiliser un soft d'archivage tel que winzip), donc il est absolument exclu de changer les pratiques. Note que le 3GPP ne fait guère mieux. Dans le monde réel, les gens/organisations/entreprises utilisent ce genre de truc et il faut faire avec.
Conclusion: après avoir longuement lutté, j'ai dû revenir sous Mac pour avoir un OS Unix à peu près potable tout en ayant MS Word (il y a une autre raison aussi: l'hibernation "juste marche", tout comme le Wi-Fi, le branchement d'un écran externe et la gestion d'énergie, et l'autonomie est double de celle de mon ancien vieux PC/Linux). Mais franchement, j'aimerais me passer du Mac, surtout que la stabilité de Maverick laisse à désirer (< troll > on dirait presque une Ubuntu < /troll > :)
Il permet de faire des divergences/branches/commentaires/vote/fusion sur des parties de document ? Il permet de détecter les blocs déplacés ? Il a une interface WYSIWYG aussi complète et facile d'usage que MS Word ou Google Docs (avec support des tableaux, équations, références, illustrations, etc.) ? Il est déployable facilement ?
Est-ce que tu as regardé les fonctionnalités collaboratives de libreoffice
Si tu parles du mode révision, la réponse est oui. Mais c'est analogue à MS Word (donc pas la possibilité de diverger/commenter/voter/merger différentes propositions, ou alors j'ai zappé ça). Donc ça ne marche que si les collaborateurs travaillent ensemble de manière synchrone et non conflictuelle.
J'avais vu il y a quelques mois, qu'il était possible de faire du diff avec de l'odt (…)
Note que j'ai juste introduit l'idée, mais git/diff ne permet pas aisément d'identifier les blocs de texte déplacés (ils sont seulement affichés comme supprimé+ajouté)
As-tu considéré une solution sérieuse de composition (c'est ce que me donne mon dictionnaire comme traduction de "typesetting") telle que TeX/LaTeX ?
On parle de travail collaboratif, avec d'autres gens qui ne sont pas geek et ne lâcheront pas leurs habitudes avec MS Office + meeting si facilement. Une interface WYSIWYG est indispensable (pas forcément client lourd, une interface web à la Google Docs pourrait aussi faire l'affaire, mais certainement pas du LaTeX !). Et je ne suis pas responsable de ce sujet, j'essaie juste d'être force de proposition pour qu'on puisse faire plus de web-meetings et moins de meetings physiques. Mais les outils appropriés n'existent malheureusement pas.
le principal truc qui m'empêche d'utiliser LibO au bureau (en travail collaboratif sur des documents .docx) est qu'il parse l'ensemble du document pour le convertir dans sa représentation interne, et du coup on perd de l'information au passage lors de la reconversion en .docx à l'enregistrement (mise en forme cassée, etc). J'ai cru comprendre qu'un travail était en cours pour que le document enregistré à la fin ne touche que les noeuds OOXML nécessaires (correspondant aux zones du document modifiées par l'utilisateur), comme le font les suite Office sur Android. Ce serait vraiment bien => est-il possible d'en savoir plus ? (N.B. accessoirement, je ne peux pas non plus ouvrir les fichiers embarqués dans un .docx (par exemple un .pdf ou un autre .docx embarqué dans un .docx conteneur)).
suggestion: une fonctionnalité qui me manque (et qui n'existe nulle part à ma connaissance) est la possibilité de faire des "branches" (un peu à la git) correspondant à différentes formulations de texte, et discuter/voter ensuite sur la formulation préférée.
je termine par un troll: pourquoi Glade ? (surtout en 2014 vu l'état de Gtk+ vs QT5, et sur un produit éminemment multi plate-formes. OK… je n'ai qu'à contribuer, mais bon, je n'ai pas pu m'empêcher de le dire :)
Aptitude est un frontal convivial à dpkg, l'installeur de paquets. Apt est un autre frontal, en ligne de commande. Synaptic est une interface graphique pour Apt.
Il me semblait avoir lu que aptitude était deprecated (au moins sur Ubuntu, je ne suis pas sûr concernant Debian) ?
un solveur de dépendance
aptitude a un solveur différent de apt-get mais ça n'a jamais totalement marché pour moi. Par contre je lis des choses intéressantes concernant ce que saurait faire le solveur du projet Mancoosi avec apt-get.
Si depuis des années, Qt est libre et que KDE n'ai pas parvenu à (clairement) s'imposer face au bureau GNOME, il faut peut-être en tirer la conclusion qui est que, GNOME a lui aussi ses avantages et qu'il convient mieux à certains utilisateurs et (soyons fou) que Gtk+ convient mieux à certains développeurs aussi.
Peut-être que le soutien "politique" de la FSF et de RedHat aident aussi… (et puis, le souhait un peu légitime d'avoir "one desktop to rule them all" pour éviter la fragmentation. Puisque ça ne devait pas être KDE, ils ont tout fait pour que ce soit Gnome. Manque de bol, il était techniquement très inférieur).
mais il ne faut pas oublier le problème de licence qui est à l'origine de ce gâchis. Quand il était interdit de distribuer des versions modifiées de Qt, il était légitime de ne pas utiliser ce toolkit pour bâtir un bureau libre. La vraie faute elle est là et elle repose sur les épaules de TrollTech.
La communauté aurait aussi pu développer un "OpenQT" avec une API compatible, le tout sous licence LGPL, plutôt que de partir dans des guerres de religion C vs C++ et réinventer la roue…
comme le font les constructeurs de smartphone chinois avec Android
(…)
Ce que je crois moi c'est qu'ils envisagent une libération à la Solaris: le source est dispo (pour tout le monde ou seulement après signature de NDA) mais tu n'as que le droit d'envoyer tes patches à Jolla.
Mouais, quand on voit le respect de la GPL par les fabricants de chipset / ODMs chinois (" I've written e-mails to few producers (ZOPO, Cubot, THL), and even that I've gotten replies from ZOPO and THL, they don't want to share anything, nor the kernel, nor any other sources ") on peut se dire que même ça est risqué… :(
Même un Linux, ce n'est pas toujours évident (j'ai un vieux smartphone à base de SoC Mediatek pour lequel je n'ai jamais réussi à obtenir les sources => pas possible de recompiler kernel + Cyanogenmod).
Pour rappel, dans le monde ARM, il n'y a pas d'ACPI, et le device-tree n'est pas encore généralisé => pas de kernel générique. Une machine == un kernel. S'il te manque le device-tree ou les board files pour compiler le kernel pour ta machine, tu l'as dans l'OS !
Je viens de faire la MAJ de mon Samsung GS3 LTE (i9305) vers le Android stock 4.3. J'aurais dû faire plus attention : cette MAJ inclue Knox, qui change le bootloader et laisse une trace indélébile (eFuse) si je fais quoi que ce soit non prévu par Samsung (comme rooter mon téléphone, installer CWM recovery, tenter de faire in rollback sur le bootloader, etc.). Pour l'instant, griller le eFuse semble juste interdire le changement de bootloader et l'utilisation de container knox (mais ce n'est pas clair pour moi, car je lis aussi qu'il ne serait plus possible de réinstaller de firmware officiels via Odin une fois le eFuse grillé. Or si j'installe MIUI ou Omnirom, je souhaite garder la possibilité de remettre un firmware officiel, ne serait-ce que parce que certaines fonctionnalités comme EAP-SIM ne sont dispo que sur ces derniers…)
Bref, entre UEFI+trusted boot côté PC, et la même chose (bootloaders verrouillés, eFuse, etc.) côté smartphones, garder le contrôle de sa machine devient de plus incertain (car ça n'est pas que du reverse-engineering à effectuer, mais de la crypto à casser…)
"se concentrer" == commencer par convaincre Mediatek/Qualcomm/Samsung/nvidia de sortir un kernel et des drivers libres ! (et côté baseband, tu peux généralement te gratter, à part OsmocomBB)
Pour les bagnoles, je pense a priori (me corriger si je me trompe) que la répartition du bilan énergétique entre fabrication/utilisation est plus équilibrée. Du coup il pourrait être utile d'avoir une prime à la casse ciblée (+ augmentation de la TIPP progressive) pour remplacer les véhicules lourds/énergivores actuels par des mobylettes ou "2CV nouvelle version" qui consomment 1 à 2 litres au 100… (ça serait d'ailleurs peut-être plus urgent et plus utile à budget constant que déployer de nouvelles lignes de tram en grande banlieue, qui de toute façon n'entraineront qu'un report modal négligeable).
les TIC pèsent, avec 1 500 teraWatt-heure d'électricité consommée par an, pour 10 % de la production mondiale. Soit la production de l'Allemagne et du Japon
[^] # Re: Intéressant de mesurer les forces en présence
Posté par karteum59 (site web personnel) . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 2. Dernière modification le 16 février 2014 à 11:52.
Ah merci, je ne savais pas…
Mais du coup, il y a un bug d'intégration avec LXDE puisque le réglage "ne pas lancer l'hibernation quand on ferme l'écran" ne fonctionne pas et oblige à aller changer le fichier de conf.
Oui évidemment ! (pour le coup ce n'était pas là la question. J'étais juste surpris que Canonical se base sur la version mergée avec systemd)
[^] # Re: Intéressant de mesurer les forces en présence
Posté par karteum59 (site web personnel) . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 2.
Bon après, Debian a choisi systemd comme init par défaut. ça ne veut pas dire que c'est le seul. Canonical aurait pu choisir de continuer à supporter un autre init.
N.B. sur une LUbuntu 13.10 récemment installée au bureau, j'ai observé que le réglage "ne pas mettre en veille lors de la fermeture de l'écran" était ignoré par la machine, et qu'il fallait que j'aille trifouiller
/etc/systemd/logind.confpour paramétrer "HandleLidSwitch=ignore" pour que ça (re)marche. Il s'agit d'une installation LUbuntu 13.10 de base sur un PC Dell D410 => qqun sait me dire ce que systemd/logind fait ici alors que je n'ai rien demandé ? (ps axrenvoiesystemd-logindetsystemd-udevd)<troll>Personnellement j'aimais bien l'init de Pardus</troll>[^] # Re: OpenGL ES et Sandy Bridge
Posté par karteum59 (site web personnel) . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 4.
Demande toi: l'hafnium est présent en quelle proportion dans le minerais ? Sa consommation évolue à quel rythme par rapport à l'ensemble du stock ?
Sauf que nos soucis ne se limitent pas au platine (qui représente des faibles masses parmi tout ce qui est miné), mais plein d'autre chose aux ordres de grandeurs considérablement plus élevés. Tu vas faire quoi pour le zinc et le cuivre ?
Encore une fois: qu'on sache ramener 3 cailloux n'est pas le sujet (et si dans le cas du platine, ramener 3 cailloux résoud le souci, tant mieux. Mais j'en doute…)
Il y a comme un léger décalage entre "plus sérieusement" et "une fois qu'on saura comment pousser un astéroïde" ! Non, ça n'est pas (et à mon avis ne sera jamais) faisable. Je pense que tu surestimes beaucoup le niveau technologique de notre espèce. L'homme n'est pas un dieu au dessus des lois de la physique ! Dans la vraie vie, ça ne marche pas comme dans star wars.
Où ça ?
Hormis la lune et les satellites artificiels (+ leurs débris), il n'y a pas d'astéroïde en orbite stable autour de notre planète. Encore moins d'objet celeste exploitable sur le plan minier !
Encore une fois: regarde combien d'énergie (et de matières) il faut pour satelliser un kg. Idem si tu veux imaginer de les "découper" (N.B. sans moteur thermique, puisqu'il n'y a pas d'oxygène, donc pas d'usage du pétrole hein :). De même pour ramener sur terre des volumes (donc des masses) élevées sans que ça se désintègre…
[^] # Re: OpenGL ES et Sandy Bridge
Posté par karteum59 (site web personnel) . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 5. Dernière modification le 09 février 2014 à 19:49.
J'ai déjà mis ce lien dans mon post précédent plus haut.
L'exploitation spatiale restera à mon avis à jamais de la science-fiction. Le fait que tu arrives éventuellement à ramener un jour 3 cailloux intacts d'un astéroïde ou planetoïde voisin ne veut pas dire
Il n'y a pas d'alternative à la "chasse aux gaspis" !
Bien sûr que si
[^] # Re: OpenGL ES et Sandy Bridge
Posté par karteum59 (site web personnel) . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 4.
Et donc justement: dès lors qu'il y a "architecture de shaders unifiés" (donc un HW 100% programmable), qu'est-ce qui s'oppose à ce que ça supporte les mêmes fonctionnalités que les générations suivantes ?
(je ne suis pas spécialiste => est-ce que OpenGL 4.0 ou OpenGL-ES 3.0 présument des fonctionnalités HW particulières qui seraient absentes des cartes OpenGL2.1 par exemple ?)
[^] # Re: OpenGL ES et Sandy Bridge
Posté par karteum59 (site web personnel) . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 4. Dernière modification le 08 février 2014 à 17:50.
Au fait, en complément de ma réponse précédente, j'ajouterais que même si une solution technique est trouvée pour rendre le thorium utilisable, cela ne préjuge pas de la faisabilité de son passage à l'échelle et de sa durabilité. Car même si le Thorium lui-même est abondant sur terre, ses dépendances pourraient être rares. Par exemple, le combustible MOX des centrales actuelles est entouré de gaines de Zirconium, dont les réserves sont estimées à 40 ans (au rythme actuel, donc sans prendre en compte un éventuel accroissement de la demande). Dans un système complexe comme une centrale au thorium, il est à craindre que certains éléments minéraux (autres que le thorium lui-même) deviennent un goulet d'étranglement. Mais personne ne semble en avoir conscience, la spécialisation à outrance dans notre société et notre mode de pensée présumant des ressources habituelles infinies fait qu'on manque de systémiciens et de personnes ayant une vision un peu globale.
Bref, considérer que le thorium est la solution-miracle à nos problèmes est encore très prématuré…
[^] # Re: OpenGL ES et Sandy Bridge
Posté par karteum59 (site web personnel) . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 5.
1°/ Le hafnium ne fait pas parti des composés dits "terres rares" au sens chimique du terme. Et je n'ai pas inventé le fait que la plupart des gisements économiquement exploitables seraient épuisés vers 2018.
2°/ faux problème ? Comme toute ressource finie et non renouvelable, la production de terres rares atteindra un jour un pic inexorable !
3°/ Même dans le cas où les terres rares ne sont pas toujours "rares" dans la croûte (ça dépend des éléments chimiques), elles sont globalement très peu concentrées. Pour cela, leur exploitation est très polluante et aussi très énergivore. Or, on va aussi manquer d'énergie dans les années qui viennent…
4°/ La filière thorium n'est pas au point. Elle est présentée comme un remède miracle, mais pour l'instant des difficultés techniques restent encore non résolues (et par définition, on ne sait pas si/comment on pourra les résoudre !)
# OpenGL ES et Sandy Bridge
Posté par karteum59 (site web personnel) . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 4. Dernière modification le 08 février 2014 à 13:59.
Il y a une raison technique qui explique le non-support sur les générations précédentes ? Pour ma part, j'ai un core i5 M520 avec une puce graphique "gen5", que j'estime encore suffisamment récent pour ne pas justifier un changement de machine, et il me semblait que la gen5 disposait déjà d'un pipeline entièrement programmable (par opposition au pipeline fixe conçu pour OpenGL 1.x qui fait que les vieux laptops avec un GMA950 ne pourront jamais supporter les shaders). Accessoirement sur la page sandy bridge de wikipedia, on lit "utilisation d'hafnium comme isolant au sein des transistors des processeurs", sauf que "Les gisements exploitables de hafnium à un coût acceptable seront épuisés autour de 2018" donc ce serait bien de ne pas changer de machine tous les 3-4 matins…
[^] # Re: remarques
Posté par karteum59 (site web personnel) . En réponse à la dépêche LibreOffice 4.2.0 est disponible. Évalué à 3. Dernière modification le 06 février 2014 à 15:32.
Il faudrait que tu précises ta question :
Conclusion: après avoir longuement lutté, j'ai dû revenir sous Mac pour avoir un OS Unix à peu près potable tout en ayant MS Word (il y a une autre raison aussi: l'hibernation "juste marche", tout comme le Wi-Fi, le branchement d'un écran externe et la gestion d'énergie, et l'autonomie est double de celle de mon ancien vieux PC/Linux). Mais franchement, j'aimerais me passer du Mac, surtout que la stabilité de Maverick laisse à désirer (< troll > on dirait presque une Ubuntu < /troll > :)
[^] # Re: remarques
Posté par karteum59 (site web personnel) . En réponse à la dépêche LibreOffice 4.2.0 est disponible. Évalué à 2.
Je ne sais pas "comment ça marche" dans le détail, mais je sais juste que je n'arrive pas à ouvrir les PJ dans ce genre de fichier sous Linux.
[^] # Re: remarques
Posté par karteum59 (site web personnel) . En réponse à la dépêche LibreOffice 4.2.0 est disponible. Évalué à 2. Dernière modification le 05 février 2014 à 18:40.
Il permet de faire des divergences/branches/commentaires/vote/fusion sur des parties de document ? Il permet de détecter les blocs déplacés ? Il a une interface WYSIWYG aussi complète et facile d'usage que MS Word ou Google Docs (avec support des tableaux, équations, références, illustrations, etc.) ? Il est déployable facilement ?
Si oui, ça m'intéresse !
[^] # Re: remarques
Posté par karteum59 (site web personnel) . En réponse à la dépêche LibreOffice 4.2.0 est disponible. Évalué à 2. Dernière modification le 05 février 2014 à 15:11.
Si tu parles du mode révision, la réponse est oui. Mais c'est analogue à MS Word (donc pas la possibilité de diverger/commenter/voter/merger différentes propositions, ou alors j'ai zappé ça). Donc ça ne marche que si les collaborateurs travaillent ensemble de manière synchrone et non conflictuelle.
Note que j'ai juste introduit l'idée, mais git/diff ne permet pas aisément d'identifier les blocs de texte déplacés (ils sont seulement affichés comme supprimé+ajouté)
On parle de travail collaboratif, avec d'autres gens qui ne sont pas geek et ne lâcheront pas leurs habitudes avec MS Office + meeting si facilement. Une interface WYSIWYG est indispensable (pas forcément client lourd, une interface web à la Google Docs pourrait aussi faire l'affaire, mais certainement pas du LaTeX !). Et je ne suis pas responsable de ce sujet, j'essaie juste d'être force de proposition pour qu'on puisse faire plus de web-meetings et moins de meetings physiques. Mais les outils appropriés n'existent malheureusement pas.
# remarques
Posté par karteum59 (site web personnel) . En réponse à la dépêche LibreOffice 4.2.0 est disponible. Évalué à 7.
Bravo et merci aux contributeurs !
Trois remarques/questions:
# Crowfunding
Posté par karteum59 (site web personnel) . En réponse au journal [bookmark] Du crowdfunding pour libérer Revenge of the Cats: Ethernet. Évalué à 5. Dernière modification le 30 janvier 2014 à 14:08.
"Crowfunding" c'est du financement d'élevage de corbeaux ? :)
--> []
# Gameduino ?
Posté par karteum59 (site web personnel) . En réponse à la dépêche Bitbox, la mini console ARM DIY. Évalué à 4.
Ce serait pas un peu le même concept que la Gameduino ?
(et je découvre accessoirement que la Gameduino 2 permet de belles choses ! :)
[^] # Re: Question
Posté par karteum59 (site web personnel) . En réponse au journal apti 0.5 : frontend à aptitude. Évalué à 2.
Il me semblait avoir lu que aptitude était deprecated (au moins sur Ubuntu, je ne suis pas sûr concernant Debian) ?
aptitude a un solveur différent de apt-get mais ça n'a jamais totalement marché pour moi. Par contre je lis des choses intéressantes concernant ce que saurait faire le solveur du projet Mancoosi avec apt-get.
[^] # Re: Uchronie
Posté par karteum59 (site web personnel) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 8.
Peut-être que le soutien "politique" de la FSF et de RedHat aident aussi… (et puis, le souhait un peu légitime d'avoir "one desktop to rule them all" pour éviter la fragmentation. Puisque ça ne devait pas être KDE, ils ont tout fait pour que ce soit Gnome. Manque de bol, il était techniquement très inférieur).
[^] # Re: Uchronie
Posté par karteum59 (site web personnel) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 4. Dernière modification le 14 janvier 2014 à 12:32.
La communauté aurait aussi pu développer un "OpenQT" avec une API compatible, le tout sous licence LGPL, plutôt que de partir dans des guerres de religion C vs C++ et réinventer la roue…
[^] # Re: Mercurial
Posté par karteum59 (site web personnel) . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 2.
Si >80% du temps est dépensé dans <20% du code, ce n'est pas déconnant…
[^] # Re: Aucune surprise
Posté par karteum59 (site web personnel) . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 2.
Mouais, quand on voit le respect de la GPL par les fabricants de chipset / ODMs chinois (" I've written e-mails to few producers (ZOPO, Cubot, THL), and even that I've gotten replies from ZOPO and THL, they don't want to share anything, nor the kernel, nor any other sources ") on peut se dire que même ça est risqué… :(
[^] # Re: Aucune surprise
Posté par karteum59 (site web personnel) . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 2. Dernière modification le 09 janvier 2014 à 21:28.
Même un Linux, ce n'est pas toujours évident (j'ai un vieux smartphone à base de SoC Mediatek pour lequel je n'ai jamais réussi à obtenir les sources => pas possible de recompiler kernel + Cyanogenmod).
Pour rappel, dans le monde ARM, il n'y a pas d'ACPI, et le device-tree n'est pas encore généralisé => pas de kernel générique. Une machine == un kernel. S'il te manque le device-tree ou les board files pour compiler le kernel pour ta machine, tu l'as dans l'OS !
[^] # Re: L'histoire se repette !
Posté par karteum59 (site web personnel) . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 3.
Je viens de faire la MAJ de mon Samsung GS3 LTE (i9305) vers le Android stock 4.3. J'aurais dû faire plus attention : cette MAJ inclue Knox, qui change le bootloader et laisse une trace indélébile (eFuse) si je fais quoi que ce soit non prévu par Samsung (comme rooter mon téléphone, installer CWM recovery, tenter de faire in rollback sur le bootloader, etc.). Pour l'instant, griller le eFuse semble juste interdire le changement de bootloader et l'utilisation de container knox (mais ce n'est pas clair pour moi, car je lis aussi qu'il ne serait plus possible de réinstaller de firmware officiels via Odin une fois le eFuse grillé. Or si j'installe MIUI ou Omnirom, je souhaite garder la possibilité de remettre un firmware officiel, ne serait-ce que parce que certaines fonctionnalités comme EAP-SIM ne sont dispo que sur ces derniers…)
Bref, entre UEFI+trusted boot côté PC, et la même chose (bootloaders verrouillés, eFuse, etc.) côté smartphones, garder le contrôle de sa machine devient de plus incertain (car ça n'est pas que du reverse-engineering à effectuer, mais de la crypto à casser…)
[^] # Re: L'histoire se repette !
Posté par karteum59 (site web personnel) . En réponse au journal Sailfish OS embarque une partie propriétaire. Évalué à 2.
"se concentrer" == commencer par convaincre Mediatek/Qualcomm/Samsung/nvidia de sortir un kernel et des drivers libres ! (et côté baseband, tu peux généralement te gratter, à part OsmocomBB)
[^] # Re: Et les cartes graphiques ?
Posté par karteum59 (site web personnel) . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 10.
Pour les bagnoles, je pense a priori (me corriger si je me trompe) que la répartition du bilan énergétique entre fabrication/utilisation est plus équilibrée. Du coup il pourrait être utile d'avoir une prime à la casse ciblée (+ augmentation de la TIPP progressive) pour remplacer les véhicules lourds/énergivores actuels par des mobylettes ou "2CV nouvelle version" qui consomment 1 à 2 litres au 100… (ça serait d'ailleurs peut-être plus urgent et plus utile à budget constant que déployer de nouvelles lignes de tram en grande banlieue, qui de toute façon n'entraineront qu'un report modal négligeable).
[^] # Re: Et les cartes graphiques ?
Posté par karteum59 (site web personnel) . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 10. Dernière modification le 09 janvier 2014 à 01:17.
Par ailleurs en parlant de consommation, il parait bon de rappeler que l'utilisation d'une machine pèse très peu par rapport à ce que nécessite sa fabrication. Donc le meilleur moyen de consommer moins, c'est d'utiliser nos machines longtemps (même si elles sont grosses, obsolètes et energivores !)