karteum59 a écrit 864 commentaires

En fait, on est en train de mélanger les sujets

• il est légitime que le "système de base" (kernel, drivers, libc, xorg, pa…) soit stable. Il est aussi légitime que la mise à jour d'une appli ne puisse rien casser d'autre que l'appli elle-même
• l'utilisateur souhaite que ses jeux, son firefox, ses outils de dev, etc. soient dans une version récente (comme c'est le cas sous Mac/Win, dont le système de base n'est pas en rolling-release pour autant)

Les applis ont des dépendances. En rolling-release, peut-être que mettre à jour l'appX va nécessiter de mettre à jour la libY et qu'il faut donc aussi mettre à jour (ou casser) d'autres applis au passage qui n'étaient pas mûres ou dont l'utilisateur ne souhaitait pas l'upgrade. Donc une distro stable comme Debian a nécessairement des couplages assez forts (d'autant plus qu'il y a de paquets dans main). Mac/Win résolvent en partie le problème de manière radicale: chaque appli embarque ses .dll ! (ce qui outre la consommation d'espace disque, complique la correction des failles de sécu tout en étant moins efficace que le link statique). Peut-être qu'une approche intermédiaire serait de permettre à plusieurs versions d'une lib de coexister, de stocker chaque appli dans un dossier/chroot dédié, et de gérer quelle appli utilise quelle version de lib à coup de symlink/hardlink dans ledit dossier. A ce sujet, Nix semble fort sympathique ("You can have multiple versions or variants of a package installed at the same time. This is especially important when different applications have dependencies on different versions of the same package — it prevents the “DLL hell”. Because of the hashing scheme, different versions of a package end up in different paths in the Nix store, so they don’t interfere with each other."), de même que 0install ("If two programs want the same version of a library, they'll share it. Otherwise, they'll use separate copies").

j'aimerais bien voir, pour un logiciel "classique", la Feature qui n'existe QUE sous la dernière version

Il me semble que c'est à l'utilisateur d'en juger et non au développeur d'être donneur de leçons "dis moi ton besoin, je te dirai comment t'en passer".
Note que ça n'est pas nécessairement une "feature" mais ça peut être un bug corrigé, etc. Au hasard: si tu fais du dev django, tu utilises la version de Debian Stable, ou bien celle fournie par pip ? (question évidemment transposable à rails, nodejs ou à ton_framework_préféré).

je n'ai trouvé aucun OS libre qui permette de faire du fail-over + du load-balancing + les autres fonctionnalités que je voulais implémenter

OpenWRT semble aussi avoir des solutions ou-of-the-box pour le multi-wan (N.B. je n'ai pas encore testé)

http://wiki.openwrt.org/doc/uci/multiwan
http://wiki.openwrt.org/doc/howto/multiwan.failower
http://wiki.openwrt.org/doc/howto/mwan3

Il y a aussi le Banana Pi à peu près au même prix. Quant à savoir comment elles se comparent, quelqu'un a répondu ceci sur cnx-software:

The theory is:
Cortex A5: 1.57 DMIPS/MHz per core
Cortex A7: 1.9 DMIPS/MHz per core
Allwinner A20 is clocked at 1.0 GHz, Amlogic S805 @ 1.5 GHz
So single core performance: 1900 DMIPS (A20) vs 2,355 DMIPS (S805)
So even single core performance should be better with ODROID-C1.
The GPU is faster too (Mali-400 vs Mali-450).

Hardware wise, the main advantage of Banana Pi is the SATA port.

You’re more likely to get proper support via Hardkernel than SinoVoIP/BananaPi, and Hardkernel don’t spend their time spamming the internet ;-)

Il y a aussi les variantes de cubieboard, légèrement plus chères mais qui intègrent de la NAND flash (tout comme le Beaglebone Black d'ailleurs). Sinon en moins cher il y a le WRTNode, Carambola2 ou d'autres trucs encore 2x moins chers

N.B.: je recherche une info particulière sur le Pi => je lis à propos de PiFM : "It uses the hardware on the raspberry pi that is actually meant to generate spread-spectrum clock signals on the GPIO pins to output FM Radio energy" => on parle de quel "hardware meant to generate spread-spectrum clock signals on the GPIO pins" / c'est documenté où ? (corollaire: je suis curieux de savoir si on peut faire la même chose sur d'autres cartes comme le Odroid C1…)

N.B. en fait ma remarque initiale répondait surtout à Groumly qui que je trouvais un peu excessif dans son discours "le volume, on s'en fiche". L'exemple précis que j'ai donné n'était peut-être pas le mieux choisi vis à vis du sujet du post (si les sites que j'avais visité avaient utilisé .bpg, cela n'aurait pas forcément changé grand chose à ma mesaventure. Et par ailleurs je suis d'accord: quand on est à l'étranger en roaming hors de prix, on essaye tous autant que possible d'utiliser du wifi ou une SIM locale…), mais en fait je voulais surtout dire que je ne trouvais pas inutile (d'une manière générale) de faire quelques efforts pour réduire les volumes de données et penser un peu à ceux qui ont un débit très lent et/ou payent très cher !

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 y avait exactement le même problème avec JPEG jusqu'à il y a peu, et ça n'a pas empéché Firefox de l'implémenter.

Avec JPEG, vraiment ? Ce ne serait pas plutôt avec JPEG2000 ?

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)

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")

Au hasard : Gnome -> systemd -> glibc.

Lennart n'a aucun pouvoir

Bah si, Lennard a le pouvoir de refuser les patches qui visent à rendre systemd compatible avec musl…

@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 quoi systemd vous a négativement impacté

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…)

Les offres VPS chez OVH se sont bien démocratisées aussi !

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… ?)