Hum, c'est bien pour ça que j'ai dit "10 minutes" (en l'occurence dans mon cas c'était le seul moyen de changer mon billet à temps. Mais ça n'est qu'un exemple et il y a une foule d'autres situations où on peut avoir besoin d'un accès en urgence).
Non, effectivement, ca m'est jamais arrive. Comme 99.9% de la population.
Je pense que tu sous-estimes le nombre de gens qui se déplacent… comme le nombre de pays où de tels tarifs de roaming s'appliquent (au hasard: la Chine (je suis chez Free mais c'était aussi le cas quand j'étais chez Virgin). Et il y a un paquet de gens qui se rendent en Chine chaque année !)
Tu ne fais qu'appuyer mon argument, c'est un cas tres a la marge, qui ne justifie pas l'immensité de la tache en soit.
Le fait que ce ne soit pas ton problème (sic) ne signifie pas qu'alléger les sites web ne se justifie pas. Il y a aussi un paquet de gens qui ont encore une connexion internet de merde (par exemple dans beaucoup de pays d'afrique, par exemple aussi en France en 2G dans les zones rurales…)
Vu que ce qui coute tres cher sur mobile, c'est la latence, et donc l'etablissement de la connexion (les bandes passantes sont plus que raisonable, une fois la latence absorbee), va falloir une putain de difference pour combler la difference, et le cpu c'est pas gratos non plus.
Hum, toi tu ne t'es manifestement jamais retrouvé à payer 100€ de facture télécoms pour t'être connecté 10 minutes en roaming dans un pays lointain à 10 €/Mo juste pour un truc banal comme changer un billet d'avion…
Il n'y a pas qu'une question pécuniaire : le CLUF est un contrat. Si l'acheteur de la machine d'occasion est lié par toutes les clauses (même les plus enfouies, les plus obscures et les plus abusives) de ce contrat qu'il n'a pas lu, il y a comme un problème…
Mouais bon… je suis d'accord avec la remarque en règle générale, mais quand même c'est pas comme si on avait affaire à un format fermé, ou à une implémentation uniquement en JS : en l'occurence une implémentation en C de l'encodeur et du décodeur sont disponibles sur le site de F. Bellard (code-source sous licence BSD), donc libre à Mozilla/Chromium/ton_navigateur_préféré de supporter ce format en natif ! (et/ou libre à toi d'envoyer un patch, ou même simplement de patcher chez toi. Magie du libre… Du reste, je suis d'accord que patcher Mozilla/Chromium n'est sûrement pas trivial quand on débarque sur la base de code, mais peut-être est-ce plus simple pour des navigateurs légers commme Qupzilla).
En attendant, les 95% de non-geeks qui laissent JavaScript activé seront satisfaits avec cette solution à court terme.
Et accessoirement, rien n'empêche les concepteurs de sites d'être intelligent et de ne renvoyer du BPG que lorsque JS est activé (et du JPG sinon, au détriment de la qualité ou de la bande passante de l'usager).
Une solution serait peut être de faire un 3eme projet "compat-libc"
Soit, mais ça signifie un effort très significatif pour répliquer la totalité des extensions non-standard de la glibc (au lieu de n'implémenter que les fonctions utilisés par systemd)
@zenitram: Je crois que tu n'as pas lu mon commentaire (ou que tu mets les gens dans des cases…)
Je n'ai dit nulle part qu'il fallait rester sur sysvinit et que "c'était mieux avant" (il y avait clairement des problèmes à résoudre). J'ai simplement dit que j'étais agacé par une attitude qui consiste à mépriser tout ce qui sort de la cible de Lennard (tu utilises *BSD, tu utilises musl: démerde toi ! Note qu'on reproche la même chose aux éditeurs de logiciels lorsqu'ils nous opposent la PdM de Linux pour justifier la non-existence de drivers potables…) et je pense que le gros du problème aurait pu être résolu en restant davantage consensuel ("à la uselessd", comme je disais). Mais Lennard semble avoir une personnalité un peu à la Ulrich Drepper…
Moi ce que j'observe, c'est que mes distros basées sur Musl (et les BSD) ont de moins en moins de chances de pouvoir intégrer Gnome… (et non: musl n'a pas vocation à intégrer tous les GNUisms et les bloats de la glibc, tout comme les *BSD). Encore une fois: personne n'a demandé à Lennard de faire lui-même le boulot de portabilité (lennard code ce qu'il souhaite. Il a le droit de ne pas s'intéresser aux BSD ou à musl). Mais par contre il a clairement une responsabilité en refusant les patches qui lui sont envoyés pour permettre cette portabilité !
systemd n'a rien d'obligatoire
Précisément si, de plus en plus à mesure que des dépendances fortes se créent. C'est bien là le problème…
En divisant la communauté, en méprisant tout ce qui s'écarte de sa cible immédiate (Linux+GLibc), le projet a introduit une ambiance assez malsaine alors que ça aurait pu être plus consensuel et progressif (une première étape "à la uselessd" ou "à la Pardus". Je pense que beaucoup de monde s'accordait à dire que sysvinit était très imparfait. L'approche Pardus était fort sympathique AMHA : garder init car ce n'était pas le composant qui posait problème, mais refondre l'infrastructure de scripts rc derrière… Certaines expérimentations chez IBM étaient sympathiques aussi).
Créer des dépendances fortes entre composants est selon moi préjudiciable sur le long terme. Le souci de portabilité ne concerne pas que les BSD => un exemple qui m'agace : musl-libc semble très prometteuse, et certaines distributions comme Alpine l'ont déjà adopté. Mais systemd ne marche qu'avec la glibc et Lennard a clairement dit qu'il refusait de résoudre le problème ("we will rely on good APIs exposed in the generally accepted Linux API which is the one glibc exposes". Dit autrement: l'API de référence est pour lui la glibc avec toutes ses extensions et GNUisms et non juste POSIX, les autres libc n'ont qu'à réimplémenter le bloat…). Or pour autre chose que de l'embarqué (au hasard, pour une machine desktop avec Gnome), les dépendances élargies du type Gnome->systemd->glibc compliquent le passage à autre chose que systemd et par voie de conséquence empêchent durablement toute distro majeure de proposer autre chose que la glibc. La compatibilité avec musl et uclibc est pour moi un argument majeur pour toutes les alternatives à systemd — notamment uselessd !
il n'y a pas d'accélération 2D, et tout l'affichage se fait avec de l'antialiasing; c'est beau, mais c'est lent. Et en plus c'est en double buffer (ce n'était pas le cas pour BeOS) et l'un des deux buffers est en RAM centrale (l'accès en lecture à la RAM vidéo via le BUS AGP étant trop lent).
C'est un choix délibéré (parce que sur des machines récentes vous estimez que c'est plus rapide) ou c'est essentiellement un manque de temps/contributions (les drivers graphiques c'est difficile) qui ont guidé ce choix ?
nos drivers graphiques n'utilisent plus l'acceleration 2D qui permettait à BeOS de bien fonctionner sur ce genre de machines, d'abord parce qu'on veut faire du rendu avec antialiasing et que ça ne s'accélère pas aussi facilement, mais aussi parce que sur les machines récentes, le processeur est de toutes façons plus rapide que la carte graphique pour ce genre de choses
OK mais je trouve dommage que Haiku fasse le choix de ne marcher bien que sur des machines récentes (l'offre d'OS qui exige des machines récentes est assez vaste, alors que l'offre d'OS qui marche bien sur des machines anciennes est assez restreinte…)
L'antialiasing c'est sympa, mais ça reste de priorité secondaire pour moi (par rapport à avoir une machine rapide et fluide)
J'utilise Qupzilla sur des machines de ce type (mais ça reste Webkit, avec bien sûr tout ce que ça implique…). En fait, tu as raison et je reste globalement très content de Debian/LXDE (ou Fluxbox) et j'ai bien dit "se traine un peu", j'ai juste toujours un peu la nostalgie de la réactivité de mon Amiga 1200… Faudra que je teste Haiku (et Syllable) un de ces jours :)
à l'époque, je redémarrais sour BeOs pour lire les vidéos qui étaient trop lourdes pour mplayer sur mon pauvre Cyrix 133
Et maintenant ? Est-ce que Haiku est aussi efficace et permettrait de rendre une nouvelle jeunesse aux vieux PC ? (e.g. j'ai un PII-400/256Mo RAM qui dort chez moi, et sur lequel même Debian/LXDE se traine un peu…)
Et sinon, il y a aussi l'excellent site l'air du bois qui est un portail de partage collaboratif autour du travail du bois (réalisations entièrement sous licences CC) ! Le magazine "Bois+" en parle d'ailleurs dans son dernier numéro.
Sous XP A partir du SP2 ça ne marche plus (swap à mort)
Je l'ai fait tourner en SP3 avec bien moins que ça ! (idem pour LXDE)
je n'oserais pas les connecter à Internet
Oui mais quand la personne n'a rien d'autre (et pas les moyen de s'acheter une autre machine), il faut bien faire avec les moyens du bord…
A minima, on s'arrange pour que la machine soit NATtée. C'est toujours mieux que rien
je conseillerais un achat de 512 Mb de RAM
Oui bien sûr. C'est d'ailleurs ce que j'ai fait sur les Duron/Athlon que j'ai retapés (j'ai pu choper un stock de barrettes de SDRAM 512 Mo pour environ 1 € / pièce !). Mais il ne faut pas oublier que certaines machines sont limitées par leur carte-mère (par exemple le plus vieux PC en stock chez moi est un PII-400/256Mo. Je voudrais le donner mais j'avoue que j'hésite car ça commence à être un peu limite si l'usager a le malheur de lancer Firefox ou LibreOffice…).
Cela dit cette obsolescence m'agace : même quand il s'agit de machines trop limitées pour les trucs hype du moment en HTML5/flash/OpenGL/…, ces machines devraient être toujours capables de rendre au moins les mêmes services que ceux qu'elles rendaient à l'époque ! Au risque de passer pour un vieux con, je me rappelle que dans mon jeune temps, mon Amiga 1200 (68020 à 14 MHz, 2 Mo RAM) faisait tourner un OS multitâche préemptif, et des applications parfaitement utilisables (traitement de texte Wordsworth par exemple) sur lesquelles j'ai tapé de vrais textes (et j'ai également tapé un rapport de stage entier sur un Psion Séries 5 car je n'avais pas d'ordi à l'étranger - ni d'argent pour en acheter - et que c'était la seule chose qu'on m'avait prêtée…)
Va dire ça aux heureux propriétaires d'une licence winXP.
Eh bien ils mettent à jour vers Windows 7/8/10 lorsque le support finit, de la même façon qu'un utilisateur de Debian met à jour lorsque le support de sa version est arrêté
Mouais…
il faut une machine qui tienne la route (je connais bien des gens qui ont encore des Duron 1000 / 512 Mo RAM. ça marche très bien sous XP, et pas du tout sous Seven). Pas question d'envoyer à la poubelle une machine qui marche encore.
il faut payer (et les personnes en question ne roulent pas sur l'or)
(cela dit c'est une bonne occasion pour faire du prosélytisme vers Debian/LXDE… :)
Oui bien sûr que l'éducation et le vécu jouent un rôle absolument primordial, et heureusement qu'il existe (une majorité, j'espère) de gens bien ! Seulement
"individualisme" ne signifie pas "tout ou rien", et ne signifie d'ailleurs pas non plus que des choses négatives : ta capacité à penser par toi-même, à te désolidariser du groupe (voire à faire de la désobéissance civile) en sont des exemples. Il n'existe pas de "conscience commune" à notre espèce, pour le meilleur (libre arbitre, innovations à l'échelle individuelle) mais aussi pour le pire (corruption, arnaques, absence d'intelligence collective. Cf. par exemple les négociations sur le climat ou l'environnement qui n'en finissent pas de piétiner…). Or de nombreux défis qui nous attendent (sur l'environnement ou les ressources) vont nécessiter un peu plus d'inteligence collective de la part de notre espèce si l'on souhaite s'en sortir.
en situation de stress ou de pénurie, la "civilisation" est une pellicule bien mince et l'instinct de survie (ou l'individualisme) reprend souvent vite le dessus ! (pourquoi est-ce que personne ne bouge lorsque quelqu'un se fait aggresser dans le métro… ?)
Evidemment qu'elles sont super utiles (100% d'accord), mais je pense que la question posée est de savoir s'il faut une touche dédiée pour ces fonctions ou si ça peut être mappé différemment sans perte de confort. Imaginons une touche "meta" (M) facilement accessible (comme Shift), est-il absurde de mapper
"home" sur M←
"end" sur M→
"PgUp" sur M↑
"PgDown" sur M↓
"suppr" sur M+backspace
Pour les accents, est-il absurde d'avoir des touches "accent aigu", "accent grave" facilement accessibles (en touche morte, comme pour ^ et ") et supprimer les touches directes "éèùà" (ça résoudrait du même coup la difficulté d'accès aux majuscules accentuées) ?
faut-il vraiment une touche physique dédiée pour "inser", "impr-écran", "arrêt defil", "pause" ? Je ne suis pas en train de dire que les fonctions en question ne servent jamais, mais je trouve que ça pourrait être du ressort de l'OS/DE de mapper "impr-ecran" sur une touche appelée "F14" (ou sur autre chose comme "ctrl+alt+F") ?
Avec un tout petit peu d'habitude, je trouve que ça ne serait probablement pas gênant par rapport à ce qui existe (et c'est déjà en partie mis en oeuvre dans pas mal de laptops, par exemple via la touche "fonction" + flèches de directions…).
Edit: ces remarques présument toutes qu'on a deux mains. Evidemment pour un handicapé (avec une seule main), généraliser le besoin d'appuyer sur deux touches compliquerait l'usage du clavier…
Edit2: ces remarques présument aussi qu'on n'ait jamais besoin d'appuyer simultanément sur "pgdown" et ↓ (alors que ça pourrait parfois être le cas, par exemple dans des jeux). Cela dit je n'ai pas dit que ça devait nécessairement se traduire par une diminution du nombre de touches, mais juste que ces touches sur lesquelles il est écrit "PgDown", "impr-écran" pourrait simplement se nommer "F14", "F15", etc.
on se demande pourquoi toute cette intelligence n'est pas mise plus souvent au service de l'humanité
Parce que l'intelligence individuelle d'une espèce est différente de son intelligence collective.
Dans le cas des fourmis (et de nombreuses autres espèces), la coopération fait partie de leur code génétique.
Dans le cas de l'homme—et malgré nos fortes aptitudes à être des "animaux sociaux" qui ont contribué à l'établissement de civilisations telles que nous les connaissons—je pense que notre code génétique nous prédispose quand même à une large part d'individualisme (qui fait que la corruption, les inégalités, etc. existeront toujours, et que le mouvement d'ensemble de la société humaine est donc désordonné et fait nettement moins preuve "d'intelligence" au niveau macroscopique…).
One of the things, none of the distributions have ever done right is application packaging […] making binaries for linux desktop applications is a major fucking pain in the ass
Mais les constructeurs de merde, ça existe et il faut bien faire avec. D'autant que ce n'est pas complètement manichéen : faire intégrer quelque chose dans l'arbre officiel est un travail de longue haleine qui requiert une forme d'expertise et d'élitisme (et il y a donc une barrière à l'entrée, et la part de marché de Linux ne justifie pas toujours l'investissement, surtout si les API/ABI pètent tout le temps alors que chez la "concurrence" elles sont stables et bien documentées). Quand je propose à quelqu'un de passer sous Linux, il est généralement déjà équipé et ne va pas choisir son matériel spécifiquement en fonction de ce qui est bien supporté, et il faut pourtant éviter que passage sous Linux soit synonyme de régressions… (ou de potentielles régressions futures à la moindre MAJ)
Je continue de penser que proposer des APIs stables (entre versions majeures) pour les gens qui écrivent des drivers ne serait pas un luxe. Je peux comprendre que ceux qui bossent sur la gestion de la mémoire, le scheduler, etc. souhaitent garder une liberté sur l'agencement du code interne, mais je trouve qu'un driver devrait rester un bout de code qui utilise les services du noyau (au même titre qu'une appli est utilisatrice des services des libs dont elle dépend) et non quelque chose qui devrait être fortement couplé aux APIs internes.
[^] # Re: La minute philosophique.
Posté par karteum59 (site web personnel) . En réponse au journal Nouveau format d'image BPG. Évalué à 4.
Hum, c'est bien pour ça que j'ai dit "10 minutes" (en l'occurence dans mon cas c'était le seul moyen de changer mon billet à temps. Mais ça n'est qu'un exemple et il y a une foule d'autres situations où on peut avoir besoin d'un accès en urgence).
[^] # Re: La minute philosophique.
Posté par karteum59 (site web personnel) . En réponse au journal Nouveau format d'image BPG. Évalué à 6. Dernière modification le 11 décembre 2014 à 21:51.
Je pense que tu sous-estimes le nombre de gens qui se déplacent… comme le nombre de pays où de tels tarifs de roaming s'appliquent (au hasard: la Chine (je suis chez Free mais c'était aussi le cas quand j'étais chez Virgin). Et il y a un paquet de gens qui se rendent en Chine chaque année !)
Le fait que ce ne soit pas ton problème (sic) ne signifie pas qu'alléger les sites web ne se justifie pas. Il y a aussi un paquet de gens qui ont encore une connexion internet de merde (par exemple dans beaucoup de pays d'afrique, par exemple aussi en France en 2G dans les zones rurales…)
[^] # Re: La minute philosophique.
Posté par karteum59 (site web personnel) . En réponse au journal Nouveau format d'image BPG. Évalué à 5.
Hum, toi tu ne t'es manifestement jamais retrouvé à payer 100€ de facture télécoms pour t'être connecté 10 minutes en roaming dans un pays lointain à 10 €/Mo juste pour un truc banal comme changer un billet d'avion…
[^] # Re: Aucune chance de percer
Posté par karteum59 (site web personnel) . En réponse au journal Nouveau format d'image BPG. Évalué à 0.
Avec JPEG, vraiment ? Ce ne serait pas plutôt avec JPEG2000 ?
[^] # Re: Une erreur
Posté par karteum59 (site web personnel) . En réponse au journal Remboursement de Windows sur ordinateur reconditionné de marque Acer. Évalué à 3.
Il n'y a pas qu'une question pécuniaire : le CLUF est un contrat. Si l'acheteur de la machine d'occasion est lié par toutes les clauses (même les plus enfouies, les plus obscures et les plus abusives) de ce contrat qu'il n'a pas lu, il y a comme un problème…
[^] # Re: Aucune chance de percer
Posté par karteum59 (site web personnel) . En réponse au journal Nouveau format d'image BPG. Évalué à 7. Dernière modification le 09 décembre 2014 à 01:29.
Mouais bon… je suis d'accord avec la remarque en règle générale, mais quand même c'est pas comme si on avait affaire à un format fermé, ou à une implémentation uniquement en JS : en l'occurence une implémentation en C de l'encodeur et du décodeur sont disponibles sur le site de F. Bellard (code-source sous licence BSD), donc libre à Mozilla/Chromium/ton_navigateur_préféré de supporter ce format en natif ! (et/ou libre à toi d'envoyer un patch, ou même simplement de patcher chez toi. Magie du libre… Du reste, je suis d'accord que patcher Mozilla/Chromium n'est sûrement pas trivial quand on débarque sur la base de code, mais peut-être est-ce plus simple pour des navigateurs légers commme Qupzilla).
En attendant, les 95% de non-geeks qui laissent JavaScript activé seront satisfaits avec cette solution à court terme.
Et accessoirement, rien n'empêche les concepteurs de sites d'être intelligent et de ne renvoyer du BPG que lorsque JS est activé (et du JPG sinon, au détriment de la qualité ou de la bande passante de l'usager).
[^] # Re: Fonctionnalités clées.
Posté par karteum59 (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 0.
Soit, mais ça signifie un effort très significatif pour répliquer la totalité des extensions non-standard de la glibc (au lieu de n'implémenter que les fonctions utilisés par systemd)
[^] # Re: Fonctionnalités clées.
Posté par karteum59 (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 1.
Sauf qu'on ne parle pas du refus de un patch pour des raisons telles que le coding style, mais bien du refus (de principe) du moindre code additionnel pour être compatible avec autre chose que Linux/glibc ("we will rely on good APIs exposed in the generally accepted Linux API which is the one glibc exposes")
[^] # Re: Fonctionnalités clées.
Posté par karteum59 (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 5.
Au hasard : Gnome -> systemd -> glibc.
[^] # Re: Fonctionnalités clées.
Posté par karteum59 (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 1.
Bah si, Lennard a le pouvoir de refuser les patches qui visent à rendre systemd compatible avec musl…
[^] # Re: Fonctionnalités clées.
Posté par karteum59 (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 4. Dernière modification le 01 décembre 2014 à 12:31.
@zenitram: Je crois que tu n'as pas lu mon commentaire (ou que tu mets les gens dans des cases…)
Je n'ai dit nulle part qu'il fallait rester sur sysvinit et que "c'était mieux avant" (il y avait clairement des problèmes à résoudre). J'ai simplement dit que j'étais agacé par une attitude qui consiste à mépriser tout ce qui sort de la cible de Lennard (tu utilises *BSD, tu utilises musl: démerde toi ! Note qu'on reproche la même chose aux éditeurs de logiciels lorsqu'ils nous opposent la PdM de Linux pour justifier la non-existence de drivers potables…) et je pense que le gros du problème aurait pu être résolu en restant davantage consensuel ("à la uselessd", comme je disais). Mais Lennard semble avoir une personnalité un peu à la Ulrich Drepper…
Moi ce que j'observe, c'est que mes distros basées sur Musl (et les BSD) ont de moins en moins de chances de pouvoir intégrer Gnome… (et non: musl n'a pas vocation à intégrer tous les GNUisms et les bloats de la glibc, tout comme les *BSD). Encore une fois: personne n'a demandé à Lennard de faire lui-même le boulot de portabilité (lennard code ce qu'il souhaite. Il a le droit de ne pas s'intéresser aux BSD ou à musl). Mais par contre il a clairement une responsabilité en refusant les patches qui lui sont envoyés pour permettre cette portabilité !
Précisément si, de plus en plus à mesure que des dépendances fortes se créent. C'est bien là le problème…
[^] # Re: Fonctionnalités clées.
Posté par karteum59 (site web personnel) . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 10. Dernière modification le 01 décembre 2014 à 02:32.
En divisant la communauté, en méprisant tout ce qui s'écarte de sa cible immédiate (Linux+GLibc), le projet a introduit une ambiance assez malsaine alors que ça aurait pu être plus consensuel et progressif (une première étape "à la uselessd" ou "à la Pardus". Je pense que beaucoup de monde s'accordait à dire que sysvinit était très imparfait. L'approche Pardus était fort sympathique AMHA : garder init car ce n'était pas le composant qui posait problème, mais refondre l'infrastructure de scripts rc derrière… Certaines expérimentations chez IBM étaient sympathiques aussi).
Créer des dépendances fortes entre composants est selon moi préjudiciable sur le long terme. Le souci de portabilité ne concerne pas que les BSD => un exemple qui m'agace : musl-libc semble très prometteuse, et certaines distributions comme Alpine l'ont déjà adopté. Mais systemd ne marche qu'avec la glibc et Lennard a clairement dit qu'il refusait de résoudre le problème ("we will rely on good APIs exposed in the generally accepted Linux API which is the one glibc exposes". Dit autrement: l'API de référence est pour lui la glibc avec toutes ses extensions et GNUisms et non juste POSIX, les autres libc n'ont qu'à réimplémenter le bloat…). Or pour autre chose que de l'embarqué (au hasard, pour une machine desktop avec Gnome), les dépendances élargies du type Gnome->systemd->glibc compliquent le passage à autre chose que systemd et par voie de conséquence empêchent durablement toute distro majeure de proposer autre chose que la glibc. La compatibilité avec musl et uclibc est pour moi un argument majeur pour toutes les alternatives à systemd — notamment uselessd !
[^] # Re: Petites machines
Posté par karteum59 (site web personnel) . En réponse à la dépêche Haiku se lâche enfin. Évalué à 4.
C'est un choix délibéré (parce que sur des machines récentes vous estimez que c'est plus rapide) ou c'est essentiellement un manque de temps/contributions (les drivers graphiques c'est difficile) qui ont guidé ce choix ?
[^] # Re: Petites machines
Posté par karteum59 (site web personnel) . En réponse à la dépêche Haiku se lâche enfin. Évalué à 3. Dernière modification le 25 novembre 2014 à 11:39.
OK mais je trouve dommage que Haiku fasse le choix de ne marcher bien que sur des machines récentes (l'offre d'OS qui exige des machines récentes est assez vaste, alors que l'offre d'OS qui marche bien sur des machines anciennes est assez restreinte…)
L'antialiasing c'est sympa, mais ça reste de priorité secondaire pour moi (par rapport à avoir une machine rapide et fluide)
[^] # Re: Petites machines
Posté par karteum59 (site web personnel) . En réponse à la dépêche Haiku se lâche enfin. Évalué à 3.
J'utilise Qupzilla sur des machines de ce type (mais ça reste Webkit, avec bien sûr tout ce que ça implique…). En fait, tu as raison et je reste globalement très content de Debian/LXDE (ou Fluxbox) et j'ai bien dit "se traine un peu", j'ai juste toujours un peu la nostalgie de la réactivité de mon Amiga 1200… Faudra que je teste Haiku (et Syllable) un de ces jours :)
# Petites machines
Posté par karteum59 (site web personnel) . En réponse à la dépêche Haiku se lâche enfin. Évalué à 4.
Et maintenant ? Est-ce que Haiku est aussi efficace et permettrait de rendre une nouvelle jeunesse aux vieux PC ? (e.g. j'ai un PII-400/256Mo RAM qui dort chez moi, et sur lequel même Debian/LXDE se traine un peu…)
# L'air du bois
Posté par karteum59 (site web personnel) . En réponse au journal OpenDesk : plans de meubles sous licence Creative Commons. Évalué à 7.
Et sinon, il y a aussi l'excellent site l'air du bois qui est un portail de partage collaboratif autour du travail du bois (réalisations entièrement sous licences CC) ! Le magazine "Bois+" en parle d'ailleurs dans son dernier numéro.
[^] # Re: Si l'auto-hébergement ne te suffit plus (débit faible, disponibilité, etc ...)
Posté par karteum59 (site web personnel) . En réponse au journal Mon retour d'expérience sur l'auto-hébergement. Évalué à 3.
Je l'ai fait tourner en SP3 avec bien moins que ça ! (idem pour LXDE)
Oui mais quand la personne n'a rien d'autre (et pas les moyen de s'acheter une autre machine), il faut bien faire avec les moyens du bord…
A minima, on s'arrange pour que la machine soit NATtée. C'est toujours mieux que rien
Oui bien sûr. C'est d'ailleurs ce que j'ai fait sur les Duron/Athlon que j'ai retapés (j'ai pu choper un stock de barrettes de SDRAM 512 Mo pour environ 1 € / pièce !). Mais il ne faut pas oublier que certaines machines sont limitées par leur carte-mère (par exemple le plus vieux PC en stock chez moi est un PII-400/256Mo. Je voudrais le donner mais j'avoue que j'hésite car ça commence à être un peu limite si l'usager a le malheur de lancer Firefox ou LibreOffice…).
Cela dit cette obsolescence m'agace : même quand il s'agit de machines trop limitées pour les trucs hype du moment en HTML5/flash/OpenGL/…, ces machines devraient être toujours capables de rendre au moins les mêmes services que ceux qu'elles rendaient à l'époque ! Au risque de passer pour un vieux con, je me rappelle que dans mon jeune temps, mon Amiga 1200 (68020 à 14 MHz, 2 Mo RAM) faisait tourner un OS multitâche préemptif, et des applications parfaitement utilisables (traitement de texte Wordsworth par exemple) sur lesquelles j'ai tapé de vrais textes (et j'ai également tapé un rapport de stage entier sur un Psion Séries 5 car je n'avais pas d'ordi à l'étranger - ni d'argent pour en acheter - et que c'était la seule chose qu'on m'avait prêtée…)
[^] # Re: Toujours le même mélange
Posté par karteum59 (site web personnel) . En réponse au journal Mon retour d'expérience sur l'auto-hébergement. Évalué à 2.
Les offres VPS chez OVH se sont bien démocratisées aussi !
[^] # Re: Si l'auto-hébergement ne te suffit plus (débit faible, disponibilité, etc ...)
Posté par karteum59 (site web personnel) . En réponse au journal Mon retour d'expérience sur l'auto-hébergement. Évalué à 4.
Mouais…
(cela dit c'est une bonne occasion pour faire du prosélytisme vers Debian/LXDE… :)
[^] # Re: Bleuffant !
Posté par karteum59 (site web personnel) . En réponse au journal Pose toi Philae !. Évalué à 2. Dernière modification le 15 novembre 2014 à 17:55.
Oui bien sûr que l'éducation et le vécu jouent un rôle absolument primordial, et heureusement qu'il existe (une majorité, j'espère) de gens bien ! Seulement
[^] # Re: Clavier et normalisation.
Posté par karteum59 (site web personnel) . En réponse au journal Un agencement de clavier normalisé : bientôt pour la France !. Évalué à 2. Dernière modification le 15 novembre 2014 à 16:46.
Evidemment qu'elles sont super utiles (100% d'accord), mais je pense que la question posée est de savoir s'il faut une touche dédiée pour ces fonctions ou si ça peut être mappé différemment sans perte de confort. Imaginons une touche "meta" (M) facilement accessible (comme Shift), est-il absurde de mapper
Avec un tout petit peu d'habitude, je trouve que ça ne serait probablement pas gênant par rapport à ce qui existe (et c'est déjà en partie mis en oeuvre dans pas mal de laptops, par exemple via la touche "fonction" + flèches de directions…).
Edit: ces remarques présument toutes qu'on a deux mains. Evidemment pour un handicapé (avec une seule main), généraliser le besoin d'appuyer sur deux touches compliquerait l'usage du clavier…
Edit2: ces remarques présument aussi qu'on n'ait jamais besoin d'appuyer simultanément sur "pgdown" et ↓ (alors que ça pourrait parfois être le cas, par exemple dans des jeux). Cela dit je n'ai pas dit que ça devait nécessairement se traduire par une diminution du nombre de touches, mais juste que ces touches sur lesquelles il est écrit "PgDown", "impr-écran" pourrait simplement se nommer "F14", "F15", etc.
[^] # Re: Bleuffant !
Posté par karteum59 (site web personnel) . En réponse au journal Pose toi Philae !. Évalué à 2.
Parce que l'intelligence individuelle d'une espèce est différente de son intelligence collective.
Dans le cas des fourmis (et de nombreuses autres espèces), la coopération fait partie de leur code génétique.
Dans le cas de l'homme—et malgré nos fortes aptitudes à être des "animaux sociaux" qui ont contribué à l'établissement de civilisations telles que nous les connaissons—je pense que notre code génétique nous prédispose quand même à une large part d'individualisme (qui fait que la corruption, les inégalités, etc. existeront toujours, et que le mouvement d'ensemble de la société humaine est donc désordonné et fait nettement moins preuve "d'intelligence" au niveau macroscopique…).
[^] # Re: Linus a dit : « making binaries for linux […] is a major fucking pain in the ass »
Posté par karteum59 (site web personnel) . En réponse au journal Pourquoi vous ne devriez pas packager vous-même votre logiciel pour Debian ?. Évalué à 5. Dernière modification le 30 octobre 2014 à 12:40.
=> http://0install.net/
De rien :)
[^] # Re: Linus a dit : « making binaries for linux […] is a major fucking pain in the ass »
Posté par karteum59 (site web personnel) . En réponse au journal Pourquoi vous ne devriez pas packager vous-même votre logiciel pour Debian ?. Évalué à 4. Dernière modification le 30 octobre 2014 à 12:25.
Mouais si tu veux, façon de parler…
Mais les constructeurs de merde, ça existe et il faut bien faire avec. D'autant que ce n'est pas complètement manichéen : faire intégrer quelque chose dans l'arbre officiel est un travail de longue haleine qui requiert une forme d'expertise et d'élitisme (et il y a donc une barrière à l'entrée, et la part de marché de Linux ne justifie pas toujours l'investissement, surtout si les API/ABI pètent tout le temps alors que chez la "concurrence" elles sont stables et bien documentées). Quand je propose à quelqu'un de passer sous Linux, il est généralement déjà équipé et ne va pas choisir son matériel spécifiquement en fonction de ce qui est bien supporté, et il faut pourtant éviter que passage sous Linux soit synonyme de régressions… (ou de potentielles régressions futures à la moindre MAJ)
Je continue de penser que proposer des APIs stables (entre versions majeures) pour les gens qui écrivent des drivers ne serait pas un luxe. Je peux comprendre que ceux qui bossent sur la gestion de la mémoire, le scheduler, etc. souhaitent garder une liberté sur l'agencement du code interne, mais je trouve qu'un driver devrait rester un bout de code qui utilise les services du noyau (au même titre qu'une appli est utilisatrice des services des libs dont elle dépend) et non quelque chose qui devrait être fortement couplé aux APIs internes.