Ça fait très longtemps que ça existe. Il est possible en effet de faire des composants XPCOM en python (mais pas de remplacer JS par Python dans les pages XUL ou HTML). Mais ce n'est pas compilé par défaut. Il faut donc se compiler un XulRunner.
L'éditeur Komodo utilise cette fonctionnalité. Bon nombre de leurs composants sont en python. D'ailleurs, c'est eux qui ont fait le binding XPCOM pour python :-)
Le gars qui bosse dans une centrale, sait qu'il prend des risques, et qu'il peut mourir à cause de son job. Comme le gars qui s'engage dans l'armée, sait qu'il peut mourir en mission.
Bref, il est conscient que c'est un job a haut risque. À partir de là, oui, il a accepté de faire son job jusqu'au bout, parce qu'il n'y aura personne d'autre pour le faire (comme je disais, c'est pas l'habitant du coin qui va le faire, il n'a pas les compétences pour).
Cependant je ne dis pas non plus que c'est normal d'en arriver là, que c'est normal d'aller mourir pour ça. Et il faut une sacré dose de courage, en plus d'un professionnalisme sans faille, pour aller se confronter à ce genre d'accident.
à priori, la radio activité qui s'echappe actuellement, n'est pas celle émise directement par le coeur du reacteur. La demi-vie de ces éléments radio actif est apparement faible (de l'ordre de la seconde/minute). Donc cette radio-activité libérée dans l'atmosphère ne va pas durer très longtemps.
Voir des explications techniques ici, et qui montrent que la situation n'est pas aussi horrible que certains veulent le dire.
euh... je ne comprend pas. tu t'étonnes qu'il y ait des personne sur place ? Tu crois alors que les autorités laissent la centrale tout seule, sans personne pour tenter de la réparer, et que tout va se résoudre avec un coup de baguette magique ?
Désolé, le pays des bisounours, ça n'existe pas.
Oui, il y a plein de gens sur le site, pour trouver les solutions pour réparer les pompes de refroidissement, ou des solutions pour refroidir les réacteurs. Oui probablement que certains (ou tous) vont mourir, des suites des fuites de radiations, si elles sont trop fortes et si elles existent vraiment, ou des suites d'explosions ou autre.
Ça s'appelle faire son job (à priori, c'est pas le paysan du coin qui est sur place). ou se sacrifier pour la bonne cause, comme tu voudras. Si personne ne fait rien, il y a de forte chance que la situation n'empire et qu'il n'y ait pas que 11 disparus, mais des milliers.
Ça s'est passé comme ça aussi à Tchernobyl. Il a bien fallu des gens pour faire le sale boulot, et ils l'ont payé de leur vie.
Tu ne dois pas assez regarder la télé (ou le web) pour dire ça.
Pourtant il existe de nos jours les satellites, qui aurait pu fautes de journalistes sur place nous montrer la foule vu d'en haut.
Ce sont surtout des satellites militaires qui permettent de voir ce genre de chose, en temps réél, il me semble. Tu vas leur demander ? :-)
Un scénario de révolution populaire bancal: contrairement à la révolution Égyptienne et Tunisienne, les combats partent des frontières et non des grandes villes du pays.
source ? parce que toutes les cartes montrent que ce sont surtout des villes le long du littoral et autour de Tripoli qui sont aux mains des "révolutionnaires". On peut pas dire que Benghazi soit sur une frontière... À moins que les journalistes et autres sources d'informations nous mentent.
j'aimerais bien apporter ma pierre à l'édifice. Mais impossible d'éditer le truc. Ça fait une heure que j'essaye, à chaque fois, message "quelqu'un est déjà en train de modifier". Alors que dans les logs, il ne s'est rien passé.
bekerleyDB est aux bases key/value ce que sqlite est aux bases SQL : c'est de l'embarqué.
Redis est un serveur, que tu peux répliquer sur plusieurs machines. tu as de plus beaucoup plus de fonctionnalités pour manipuler les valeurs (pas seulement des chaines). Et je crois que ça stocke uniquement en mémoire, pas de fichiers, comme memcached.
Le jour où j'ai voulu programmer en Haskell, j'ai pris la doc et l'ai reposé.
Oui, donc, la programmation fonctionnelle n'est pas pour toi. Comme JS est à mis chemin entre la POO et la programmation fonctionnelle, donc ne te pose plus de question ;-)
Note: il ne faut pas essayer de faire de la POO avec JS, JS n'est pas un langage orienté objet, mais orienté prototype. C'est comme si tu essayais de faire un cube avec une machine conçue pour faire des balles.
Salut, (je suis le gars qui n'est pas un lapin de 2 semaines :-) )
Je pense qu'il y a une petite incompréhension de ta part sur la lecture du billet de Mitchell (mais je ne t'en veux pas, à l'époque pour moi aussi, la communication de Moz sur XulRunner était particulièrement floue, et j'ai dû relire plusieurs fois le billet de Mitchell pour bien comprendre les implications).
Elle a écrit effectivement que xulrunner continuait à exister comme plateforme d'application, mais uniquement pour les produits Mozilla. Et pas en tant que PRODUIT (point 4, standalone XulRunner). C'est d'ailleurs toujours le cas. Firefox et TBird sont des applis XulRunner, seul le nom du binaire change (on y trouve le application.ini par ex, et on peut même lancer des applis "xulrunner" avec firefox --app ou quelque chose comme ça)
En clair, Xulrunner continue à exister, on peut battir des applis dessus si on veut (en le patchant ou autre), Mozilla ne nous en empêche pas. Par contre, comme ce n'est PAS un PRODUIT, (comme peuvent l'etre Firefox ou Thunderbird), elle ne garantit pas la stabilité de la plateforme (en terme d'API), et ne donne pas de roadmap (la roadmap étant en fait celle de Firefox, ou plus exactement du moteur Gecko), et ne recommande pas d'utiliser XUlRunner en tant que socle commun de plusieurs applis (genre un seul XulRunner installé pour X appli), puisque la mise à jour de XulRunner peut casser des applis.
Et elle invitait ceux qui le désiraient, à aider à faire en sorte que le XulRunner standalone reste utilisable pour le maximum de personne.
Ce que j'ai dit dans mon billet, est juste que Mitchell avait enfin défini un avenir clair pour XulRunner : il n'y aura jamais un PRODUIT Xulrunner (pas de marketing, pas de site dédié, etc...). À mon grand déséspoir au final, puisque le groupe de développeur MozPad qui avaient l'ambition de faire de XulRunner un produit, n'a jamais finalement abouti à quelque chose.
Et depuis, je trouve que la communication de Mozilla est, depuis justement Prism, bien plus clair sur les softs qu'elles développent : ils commencent tous une vie dans Mozilla Labs. Et comme ça porte le nom de "labs", pour moi il n'y a plus aucune ambiguité comme à l'époque où ils ont commencé à développer XulRunner : tout ces softs sont des experimentations. Et tant que ça sort pas du labs, il ne faut pas prendre ces softs comme des trucs pérennes. C'est la définition même d'un LABoratoire ;-)
Si à l'époque des débuts de XulRunner, cela avait été développé au sein d'un "Mozilla Lab" (qui n'existait pas à l'époque), avec le recul, j'aurais peut être été plus prudent dans ma communication sur XulRunner.
Est ce que tu as besoin que ce soit dans le dépôt de ta distro préférée pour tester Firefox 4 ?
la réponse est non. Mozilla fourni des tgz pour linux (32 et 64bits). Tu désarchives dans un coin, tu lances. Ça prend 10 secondes (hors téléchargement).
Moi je n'ai pas de souci "philosophique" à utiliser du vieux matos.
Ma plus récente bécane desktop que j'utilise encore : Athlon 2600+, carte graphique geforce 2MX 64, 512Mo de ram, deux disques de 80Go.
Au niveau laptop, ormis un macbook qui a 2 ans (que j'ai récupéré suite à la fermeture de la boite où je travaillais), j'ai un dell inspiron 1525 (ceux qui était livré avec ubuntu) : dualcore 1.86ghz, 2GB de ram, dd de 80Go, et carte graphique intel GMA X3100.
Cependant, plus ça va, plus ça devient compliquer de travailler ou même s'amuser avec (tellement, que j'ai arrêté de jouer d'ailleurs).
En effet, il y a un souci technique : linux, ou d'une manière générale, les OS et logiciels sont de plus en plus gourmands.
Sur mon dell, livré avec une ubuntu 8.04, ça allait, c'était réactif, je faisais des compilations de gros projets sans trop de problèmes, Gnome était sympa à utiliser. (au point que je ne l'avais même pas remplacé par KDE, alors que je suis plutôt pro-KDE).
Upgrade vers ubuntu 10.04. La catastrophe. Tout est plus lent. La réactivité de l'interface graphique, même en désactivant tout les effets graphiques à la con, est pourrie. Je ne sais pas ce qu'ils ont foutu, mais en fouillant un peu, apparemment, le support des cartes graphique intel GMA est devenu merdique (pas que chez ubuntu, mais aussi d'autres distros apparement).
Ce qui me laisse penser que, en plus de l'embonpoint que prennent les logiciels, il y a également des régressions sur le "vieux" matos (si on peut dire 2-3 ans == vieux).
Comment voulez vous, dans ces conditions, continuer à utiliser du vieux matos ?
Ou alors effectivement, faut rester avec des vieilles distro, des vieux logiciels. ce qui devient pénible au bout d'un moment: plus de mise à jour de sécurité, on se garde les mêmes bugs pendant des années, on ne bénéficie pas des dernières évolutions qui sont censés faciliter la vie etc...
Pour mon vieux desktop, pareil, les dernières distro sont difficilement utilisables. Peut être pas coté graphisme, parce qu'à priori, ma nvidia semble être encore bien supporté, et suffisamment puissante, par contre, c'est coté mémoire et disque dur que ça commence à souffrir (au niveau capacité). Je pourrais upgrader, mais bon, le prix des mémoires DDR sont deux fois plus important que le prix des normes actuelles. Idem pour les prix des disques IDE (en achetant une carte controleur sata + disque sata, ça revient au même prix à peu près). D'un certain coté, c'est chiant de dépenser deux fois plus pour du "vieux" matos. Et c'est chiant de mettre au placard du matos qui fonctionne (sachant que mon placard commence à être bien plein, avec mon vieux TO9, mes premiers PC etc...)
Enfin bref, il faudrait que les développeurs soient aussi plus "green", et pensent à essayer de continuer à supporter du vieux matos, mais aussi à optimiser leurs softs...
pas besoin en fonction de l'UA. La balise video permet d'indiquer plusieurs liens de fichiers video de format différent. Au navigateur de prendre le format le plus adapté.
Mozilla ne peut pas intégrer H264 nativement, car Mozilla prefère mettre les millions qu'elle aurait à payer au consortium mpeg, dans d'autres ressources.
Et quand bien même elle le ferai, les distro seraient obligées de desactiver le truc, parce qu'elles auraient elle aussi à payer la dîme (en tout cas celles qui ont pignon sur rue)
Google s'en foutent, ils peuvent payer si Mpeg leur tombe dessus. Pas Mozilla.
Je n'ai quasi eu pas de souci à installer sync sur ma machine, même si c'est un peu hardu sans trop de doc. Mais ça ne m'a pas laissé un horrible souvenir.
>J'en suis venu à me demander si les devs mozilla n'avaient pas fait "exprès" de rendre l'installation trèèès complexe pour forcer l'utilisation de leur serveur...
C'est juste que c'est un projet jeune. Comme tout projet jeune et innovant, bah tout n'est pas parfait du premier coup et c'est pour ça qu'une nouvelle implémentation est en cours de dev et quasi terminée (en python).
De plus, il y a peu de retour à priori sur les install sur des serveurs perso. S'énerver tout seul dans son coin sur des dysfonctionnements d'un projet libre, ça n'aide pas ledit projet à progresser dans le bon sens ;-)
[^] # Re: GILi, GILi, GILi, ...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec des développeurs Python francophones. Évalué à 2.
Ça fait très longtemps que ça existe. Il est possible en effet de faire des composants XPCOM en python (mais pas de remplacer JS par Python dans les pages XUL ou HTML). Mais ce n'est pas compilé par défaut. Il faut donc se compiler un XulRunner.
L'éditeur Komodo utilise cette fonctionnalité. Bon nombre de leurs composants sont en python. D'ailleurs, c'est eux qui ont fait le binding XPCOM pour python :-)
[^] # Re: Ce n'est pas fini
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Explosion dans une centrale nucléaire au Japon. Évalué à 3.
Le gars qui bosse dans une centrale, sait qu'il prend des risques, et qu'il peut mourir à cause de son job. Comme le gars qui s'engage dans l'armée, sait qu'il peut mourir en mission.
Bref, il est conscient que c'est un job a haut risque. À partir de là, oui, il a accepté de faire son job jusqu'au bout, parce qu'il n'y aura personne d'autre pour le faire (comme je disais, c'est pas l'habitant du coin qui va le faire, il n'a pas les compétences pour).
Cependant je ne dis pas non plus que c'est normal d'en arriver là, que c'est normal d'aller mourir pour ça. Et il faut une sacré dose de courage, en plus d'un professionnalisme sans faille, pour aller se confronter à ce genre d'accident.
Actuellement, il y a 50 personnes sur le site pour tenter de limiter les dégâts. Pensons à eux.
[^] # Re: Ce n'est pas fini
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Explosion dans une centrale nucléaire au Japon. Évalué à 0.
à priori, la radio activité qui s'echappe actuellement, n'est pas celle émise directement par le coeur du reacteur. La demi-vie de ces éléments radio actif est apparement faible (de l'ordre de la seconde/minute). Donc cette radio-activité libérée dans l'atmosphère ne va pas durer très longtemps.
Voir des explications techniques ici, et qui montrent que la situation n'est pas aussi horrible que certains veulent le dire.
[^] # Re: Ce n'est pas fini
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Explosion dans une centrale nucléaire au Japon. Évalué à 6.
euh... je ne comprend pas. tu t'étonnes qu'il y ait des personne sur place ? Tu crois alors que les autorités laissent la centrale tout seule, sans personne pour tenter de la réparer, et que tout va se résoudre avec un coup de baguette magique ?
Désolé, le pays des bisounours, ça n'existe pas.
Oui, il y a plein de gens sur le site, pour trouver les solutions pour réparer les pompes de refroidissement, ou des solutions pour refroidir les réacteurs. Oui probablement que certains (ou tous) vont mourir, des suites des fuites de radiations, si elles sont trop fortes et si elles existent vraiment, ou des suites d'explosions ou autre.
Ça s'appelle faire son job (à priori, c'est pas le paysan du coin qui est sur place). ou se sacrifier pour la bonne cause, comme tu voudras. Si personne ne fait rien, il y a de forte chance que la situation n'empire et qu'il n'y ait pas que 11 disparus, mais des milliers.
Ça s'est passé comme ça aussi à Tchernobyl. Il a bien fallu des gens pour faire le sale boulot, et ils l'ont payé de leur vie.
[^] # Re: GILi, GILi, GILi, ...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec des développeurs Python francophones. Évalué à 2.
J'ai ouïe dire que Tarek est très occupé chez Mozilla (à faire du Python bien sûr) :-)
<mavie>Il m'a d'ailleurs bien longuement convaincu de passer à Python, mais j'ai toujours pas eu le temps de m'y mettre sérieusement..</mavie>
# pas convaincu
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal معمر القذافي Colonel Kadhafi - crie au loup ! Et si le loup était dans la bergerie ?. Évalué à 8.
Tu ne dois pas assez regarder la télé (ou le web) pour dire ça.
Ce sont surtout des satellites militaires qui permettent de voir ce genre de chose, en temps réél, il me semble. Tu vas leur demander ? :-)
source ? parce que toutes les cartes montrent que ce sont surtout des villes le long du littoral et autour de Tripoli qui sont aux mains des "révolutionnaires". On peut pas dire que Benghazi soit sur une frontière... À moins que les journalistes et autres sources d'informations nous mentent.
Ta théorie ne me convainc pas...
[^] # Re: Et pour ceux qui s'ennuie
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Firefox 4 RC1. Évalué à 2.
oui merci :)
[^] # Re: Et pour ceux qui s'ennuie
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Firefox 4 RC1. Évalué à 2.
j'aimerais bien apporter ma pierre à l'édifice. Mais impossible d'éditer le truc. Ça fait une heure que j'essaye, à chaque fois, message "quelqu'un est déjà en train de modifier". Alors que dans les logs, il ne s'est rien passé.
Bref, on dirait qu'il y a bug.
[^] # Re: paquet debian
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Firefox 4 RC1. Évalué à 1.
Mozilla ne fournit pas de paquet linux. Elle laisse les distribs le faire. Regarde dans les backports, ou autres dépots experimentaux.
[^] # Re: 64 bits
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Firefox 4 RC1. Évalué à 5.
pour la 64bits, si elle ne t'ai pas proposée : ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/4.0rc1/linux-x86_64/
[^] # Re: Et les perfs?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Redis en version 2.2. Évalué à 2.
bekerleyDB est aux bases key/value ce que sqlite est aux bases SQL : c'est de l'embarqué.
Redis est un serveur, que tu peux répliquer sur plusieurs machines. tu as de plus beaucoup plus de fonctionnalités pour manipuler les valeurs (pas seulement des chaines). Et je crois que ça stocke uniquement en mémoire, pas de fichiers, comme memcached.
# programmation fonctionnelle
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Javascript: mais pourquoi ?. Évalué à 8.
Oui, donc, la programmation fonctionnelle n'est pas pour toi. Comme JS est à mis chemin entre la POO et la programmation fonctionnelle, donc ne te pose plus de question ;-)
Note: il ne faut pas essayer de faire de la POO avec JS, JS n'est pas un langage orienté objet, mais orienté prototype. C'est comme si tu essayais de faire un cube avec une machine conçue pour faire des balles.
[^] # Re: javascript : un peu plus loin
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Javascript: mais pourquoi ?. Évalué à 1.
ah bon ? https://developer.mozilla.org/en/JavaScript (voir les pages de chaque version)
Et Ecmascript 5, que sont en train d'adopter tout les navs ?
[^] # Re: stop le fanboy
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Nouveau coup de tonnerre attendu. Évalué à -4.
bof, si ce journal se veut ironique, je trouve que c'est très mal rédigé alors (malgré le pseudo)
# stop le fanboy
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Nouveau coup de tonnerre attendu. Évalué à -10.
Mince, on m'aurait menti ? Ils racontent vraiment n'importe quoi sur wikipedia.. http://en.wikipedia.org/wiki/Digital_audio_player http://en.wikipedia.org/wiki/Tablet_personal_computer
[^] # Re: PHP 5.3
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Debian 6.0 Squeeze est sortie. Évalué à 3.
[^] # Re: quelques détails...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal It's a Long Way to the Top (If You Wanna Rock 'n' Roll). Évalué à 2.
Je pense qu'il y a une petite incompréhension de ta part sur la lecture du billet de Mitchell (mais je ne t'en veux pas, à l'époque pour moi aussi, la communication de Moz sur XulRunner était particulièrement floue, et j'ai dû relire plusieurs fois le billet de Mitchell pour bien comprendre les implications).
Elle a écrit effectivement que xulrunner continuait à exister comme plateforme d'application, mais uniquement pour les produits Mozilla. Et pas en tant que PRODUIT (point 4, standalone XulRunner). C'est d'ailleurs toujours le cas. Firefox et TBird sont des applis XulRunner, seul le nom du binaire change (on y trouve le application.ini par ex, et on peut même lancer des applis "xulrunner" avec firefox --app ou quelque chose comme ça)
En clair, Xulrunner continue à exister, on peut battir des applis dessus si on veut (en le patchant ou autre), Mozilla ne nous en empêche pas. Par contre, comme ce n'est PAS un PRODUIT, (comme peuvent l'etre Firefox ou Thunderbird), elle ne garantit pas la stabilité de la plateforme (en terme d'API), et ne donne pas de roadmap (la roadmap étant en fait celle de Firefox, ou plus exactement du moteur Gecko), et ne recommande pas d'utiliser XUlRunner en tant que socle commun de plusieurs applis (genre un seul XulRunner installé pour X appli), puisque la mise à jour de XulRunner peut casser des applis.
Et elle invitait ceux qui le désiraient, à aider à faire en sorte que le XulRunner standalone reste utilisable pour le maximum de personne.
Ce que j'ai dit dans mon billet, est juste que Mitchell avait enfin défini un avenir clair pour XulRunner : il n'y aura jamais un PRODUIT Xulrunner (pas de marketing, pas de site dédié, etc...). À mon grand déséspoir au final, puisque le groupe de développeur MozPad qui avaient l'ambition de faire de XulRunner un produit, n'a jamais finalement abouti à quelque chose.
J'en ai parlé plus longuement sur xulfr : http://xulfr.org/news/2007/05/22/216-le-futur-de-xulrunner-s(...)
Et depuis, je trouve que la communication de Mozilla est, depuis justement Prism, bien plus clair sur les softs qu'elles développent : ils commencent tous une vie dans Mozilla Labs. Et comme ça porte le nom de "labs", pour moi il n'y a plus aucune ambiguité comme à l'époque où ils ont commencé à développer XulRunner : tout ces softs sont des experimentations. Et tant que ça sort pas du labs, il ne faut pas prendre ces softs comme des trucs pérennes. C'est la définition même d'un LABoratoire ;-)
Si à l'époque des débuts de XulRunner, cela avait été développé au sein d'un "Mozilla Lab" (qui n'existait pas à l'époque), avec le recul, j'aurais peut être été plus prudent dans ma communication sur XulRunner.
[^] # Re: Dis donc ! c'est pas encore vendredi :)
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Firefox 4 et pilotes de cartes graphiques sous linux. Évalué à 3.
la réponse est non. Mozilla fourni des tgz pour linux (32 et 64bits). Tu désarchives dans un coin, tu lances. Ça prend 10 secondes (hors téléchargement).
http://www.mozilla.com/fr/firefox/beta/
À priori, il y a une forte proportion de linuxien qui savent faire ça (rien de sorcier, et à la limite, pas de ligne de commande à taper).
Bref, n'hésitez pas à tester, voir à rapporter des bugs (il y a même un bouton pour ça dans l'interface de la beta)
# et les softs alors ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal décroissance informatique. Évalué à 5.
Ma plus récente bécane desktop que j'utilise encore : Athlon 2600+, carte graphique geforce 2MX 64, 512Mo de ram, deux disques de 80Go.
Au niveau laptop, ormis un macbook qui a 2 ans (que j'ai récupéré suite à la fermeture de la boite où je travaillais), j'ai un dell inspiron 1525 (ceux qui était livré avec ubuntu) : dualcore 1.86ghz, 2GB de ram, dd de 80Go, et carte graphique intel GMA X3100.
Cependant, plus ça va, plus ça devient compliquer de travailler ou même s'amuser avec (tellement, que j'ai arrêté de jouer d'ailleurs).
En effet, il y a un souci technique : linux, ou d'une manière générale, les OS et logiciels sont de plus en plus gourmands.
Sur mon dell, livré avec une ubuntu 8.04, ça allait, c'était réactif, je faisais des compilations de gros projets sans trop de problèmes, Gnome était sympa à utiliser. (au point que je ne l'avais même pas remplacé par KDE, alors que je suis plutôt pro-KDE).
Upgrade vers ubuntu 10.04. La catastrophe. Tout est plus lent. La réactivité de l'interface graphique, même en désactivant tout les effets graphiques à la con, est pourrie. Je ne sais pas ce qu'ils ont foutu, mais en fouillant un peu, apparemment, le support des cartes graphique intel GMA est devenu merdique (pas que chez ubuntu, mais aussi d'autres distros apparement).
Ce qui me laisse penser que, en plus de l'embonpoint que prennent les logiciels, il y a également des régressions sur le "vieux" matos (si on peut dire 2-3 ans == vieux).
Comment voulez vous, dans ces conditions, continuer à utiliser du vieux matos ?
Ou alors effectivement, faut rester avec des vieilles distro, des vieux logiciels. ce qui devient pénible au bout d'un moment: plus de mise à jour de sécurité, on se garde les mêmes bugs pendant des années, on ne bénéficie pas des dernières évolutions qui sont censés faciliter la vie etc...
Pour mon vieux desktop, pareil, les dernières distro sont difficilement utilisables. Peut être pas coté graphisme, parce qu'à priori, ma nvidia semble être encore bien supporté, et suffisamment puissante, par contre, c'est coté mémoire et disque dur que ça commence à souffrir (au niveau capacité). Je pourrais upgrader, mais bon, le prix des mémoires DDR sont deux fois plus important que le prix des normes actuelles. Idem pour les prix des disques IDE (en achetant une carte controleur sata + disque sata, ça revient au même prix à peu près). D'un certain coté, c'est chiant de dépenser deux fois plus pour du "vieux" matos. Et c'est chiant de mettre au placard du matos qui fonctionne (sachant que mon placard commence à être bien plein, avec mon vieux TO9, mes premiers PC etc...)
Enfin bref, il faudrait que les développeurs soient aussi plus "green", et pensent à essayer de continuer à supporter du vieux matos, mais aussi à optimiser leurs softs...
[^] # Re: Google, space poneys and unicorns...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Encore un troll de moins .... Évalué à 2.
[^] # Re: Bonne nouvelle
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Encore un troll de moins .... Évalué à 2.
[^] # Re: Vive Firefox
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Des nouvelles de Mozilla. Évalué à 1.
[^] # Re: J'aiime firefox,
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Des nouvelles de Mozilla. Évalué à 1.
[^] # Re: Vive Firefox
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Des nouvelles de Mozilla. Évalué à 4.
Et quand bien même elle le ferai, les distro seraient obligées de desactiver le truc, parce qu'elles auraient elle aussi à payer la dîme (en tout cas celles qui ont pignon sur rue)
Google s'en foutent, ils peuvent payer si Mpeg leur tombe dessus. Pas Mozilla.
[^] # Re: Juste une petite réserve ...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Des nouvelles de Mozilla. Évalué à 1.
>J'en suis venu à me demander si les devs mozilla n'avaient pas fait "exprès" de rendre l'installation trèèès complexe pour forcer l'utilisation de leur serveur...
C'est juste que c'est un projet jeune. Comme tout projet jeune et innovant, bah tout n'est pas parfait du premier coup et c'est pour ça qu'une nouvelle implémentation est en cours de dev et quasi terminée (en python).
De plus, il y a peu de retour à priori sur les install sur des serveurs perso. S'énerver tout seul dans son coin sur des dysfonctionnements d'un projet libre, ça n'aide pas ledit projet à progresser dans le bon sens ;-)