freem a écrit 5059 commentaires

En C++, non. En Java si tu fait :

Dépend du type des valeurs que tu additionnes. Si ce sont des entiers, non. Si ce sont des std::string, oui. Quand on utilise un type, on est censé savoir ce que ça implique. Même si j'avoue que je trouve très dommage le fait que l'on ait pas de moyen automatisé de savoir si une exception peut être lancée sans jamais être interceptée (en C++) ainsi que le fait que l'on ne puisse pas préciser quelles exceptions peuvent être lancées par une fonction.

Pour le coup, j'ai une question sur Java: quand on déclare une fonction qui appelle des fonction qui peuvent lancer, il faut déclarer qu'elle peut lancer les exceptions des fonctions qu'elle appèle ou non? Si c'est le cas, n'est-ce pas trop lourd?

Oui, enfin, là tu la lèves toi-même donc le compilo fait son taf et t'envoie paître, normal. Je pensais plus au comportement de la STL, ou de linker avec une lib externe. Dans le cas de la STL, je suppose que ça ne pose pas de problème et qu'il existe une version sans exceptions, mais à voir le comportement de GCC, j'imagine que pour les lib externes, on ne peux "juste" pas linker.

Pas trop pour moi sauf quand ça touche la gestion de l'énergie sinon c'est super lourd.

Pour moi, chaque système à ses merdes, les distros linux sont loin d'être parfaites, mais windows n'est pas aussi bien intégré qu'on essaie de nous le faire croire. Ça m'est arrivé à plus d'une reprise (peut-être pas ici) de défendre windows dans des conversations (notamment quand ça parle de failles et d'instabilité, malgré que je, je l'avoue, je n'hésite pas à troller sur ces points, je pense qu'un windows bien réglé peut être sécurisé, et que l'instabilité c'est surtout celle des applications, pas de l'OS et il m'arrive donc de le défendre quand il y à trop d'encensement de linux).

Par contre, quand je vois quelqu'un dire que Linux n'est pas prêt pour le bureau, ben, je peux juste pas m'empêcher de répliquer :)
Après tout… des trucs de base de Linux sur une utilisation normale sont bien plus efficaces que sous windows, par exemple la gestion des majuscules accentuées. Et puis, au final, quand on parle du bureau linux, c'est juste un peu stupide, on compare une distribution (windows) à un kernel (linux). Donc, soit on compare deux distributions, avec leurs config par défaut, soit on compare deux kernels mais dans ce cas, on ne peut pas parler d'avantages sur le bureau, mais d'avantages dans la gestion du matériel.

Les méthodes close, il faut les appeler explicitement, contrairement aux destructeurs. Et la RAII (Resource Acquisition Is Initialisation) sert à gérer les ressources, toutes les ressources, sinon ça s'appèlerait MAII (Memory Acquisition Is Initialisation).
La mémoire étant une ressource comme une autre, elle tombe aussi sous le coup de la RAII.

Sans que ça swappe, quelques petites applications genre la musique (vers les haut-parleurs ou en streaming, testé les deux ça passe nickel), ou lire des pdf, oui, sans souci.
En général, ça swappe avec le reste, mais avec midori et pas trop de pages chargées en même temps, ça reste correct à l'usage.

Quant à office, comment dire… je ne me sers de ce genre de … logiciels… que quand je n'ai pas le choix, c'est à dire au boulot.
Après, il est évident que je ne m'amuse pas à compiler sur cette machine non plus. Je pourrais le faire à titre d'essai, mais bon…

Cette bécane me sert de jukebox, en fait, mais elle a aussi servi à dépanner quelqu'un pendant 1 mois. La personne en question jouait manifestement à wesnoth.

Oui, s'il n'y a rien de plus grave, on peut dire que ça marche sans problème. Il dit aussi dans sa démo que les touches Fn pour changer la luminosité ne marchent pas.

Ce genre de trucs, habituellement, on s'en sert d'excuse pour dire que linux, ça marche mal, quand même. Alors, windows et linux, deux poids, deux mesures?

Je ne dis pas que je ne trouve pas ça bien qu'ils arrivent à nouveau à faire des OS qui tournent sur 512Mo de RAM, hein, vu vista et seven c'est une amélioration, mais bon… faut pas pousser, on a vu que l'OS tourner, aucune application. L'OS, il sert à lancer des appli, pas à tourner à vide.

Après les exceptions posent pleins de problèmes (la performance,

Pour la performance, il semble que pour les implémentations actuelles, il n'y à de problème qu'en cas de levée d'exception, cependant.
Et d'ailleurs, pendant que j'y suis, il me semble bien qu'il soit possible de désactiver la gestion des exceptions en C++. Je n'ai aucune idée de comment ça réagit en cas d'erreur après (jamais utilisé), mais le flag de compilation -fno-except me semble fait pour ça.

Maintenant, la façon dont je me sers des exceptions personnellement, c'est pour que quand ça plante, ça plante en disant pourquoi, et pas avec un simple "segmentation fault" qui nécessite du temps passé à déboguer pour retrouver l'info. Donc la performance…

Je suis en train de lire ce livre.
L'intro est très bien foutue d'ailleurs, malheureusement, quand on arrive aux choses sérieuses (le premier jeu), il est fait mention d'une vidéo qui montre comment créer la scène du jeu (nom de la vidéo: 01a_preparation-deplacements.webm ) mais il n'y a aucun lien permettant de la télécharger (ou alors je ne l'ai pas vu).

J'ai déjà essayé d'utiliser un peu blender donc je pense que je vais réussir à surmonter ça (dans le cas de cette scène qui est plutôt simple à priori), mais pour quelqu'un qui n'a jamais lu le moindre tuto, ça risque de pas être évident.

Mais tu sais quoi, tu mets un debian etch, ça marchera nickel. C'est assez léger, une debian etch ? Une woody peut-être ?

Je fais tourner une Debian 7 avec XFCE 4.10 sur une machine dotée de moins de 200Mio de RAM, CPU 700MHz, disque dur mécanique de 80Go, "design for windows millenium". Je suis donc loin d'une etch, et je n'ai même pas 512Mo de RAM.

Peut être que perso sur son netbook, la sortie VGA ne marche pas sous W8 ?

Alors peut-on dire que ça marche sans problème?

Personnellement, je trouve que la démo est assez bluffante, toute proportions gardées.

La fluidité de l'interface graphique à vide est effectivement impressionnante. Maintenant, le fait est qu'il n'a rien fait d'autre qu'afficher taskmgr, le premier niveau de l'explorateur de fichier, le "poste de travail" ainsi que l'écran WIN+PAUSE.
Tout ce qu'il à fait était fluide, ok. Mais il n'a rien fait…

Roh, pourquoi j'ai pas été voir sur wikibook… enfin un truc ou il y à une procédure pour compiler sans avoir besoin d'IDE!

Merci bien!

Très intéressante comme vidéo.

Une carte SD (je me demande si c'est aussi lent que le disque d'origine? Je parie que non), 512Mo de RAM utilisés à 80%, et aucune application sauf le gestionnaire des tâches (qui à pris bien 10s quand même) démarrée, excepté le gestionnaire de fenêtre. Ok, c'est peut-être mieux que w7, j'en sais rien, mais… ça reste lourd.

Sans parler du fait qu'aucune application qu'il ait tenté de lancer excepté le gestionnaire de fichier et taskmgr ne se sont lancées, pour une cause assez ridicule: résolution trop faible.

Donc, ça, c'est faux: "Oh tiens, Windows 8 qui tourne sans probleme sur un EEE PC 9000 avec 512Mb RAM." puisque la plupart des trucs qu'il à tenté de lancer n'ont pas marché. Il dit que le problème de résolution ne peut pas être contourné, mais, perso sur mon netbook, il y avait un port VGA, et sur l'écran que j'y mettais je n'étais pas limité 1024x768 (résolution de l'écran intégré).

Je veux bien qu'ils aient amélioré leur API à ce niveau. Mais mince, je m'attendais à ce que tu me parles de fonctionnalité du bureau, moi, pas du kernel… puisque le sujet, c'est les innovations du bureau.

Je ne sais pas quelle technologie est responsable de ça parce que ça ne m'arrive que sur 2 ou 3 sites ce genre de limitations.

Au hasard: JS? Ce truc à tendance à être trop utilisé. J'ai noté que régulièrement même de vulgaires liens sont inutilisables sans JS :/

Mais je suis d'accord que la nouvelle interface de bitbucket est moins bien que l'ancienne.

As-tu essayé d'encapsuler les include avec extern "C"?

fichier hello.c:

#include <stdio.h>

int hello( int i, float j){puts("hello ");return 0;}

hello.h:

#ifndef HELLO_H
#define HELLO_H

extern int hello( int i, float j);

#endif

fichier world.c:

#include <stdio.h>

int world( int i, float j){puts("world! ");return 0;}

world.h:

#ifndef WORLD_H
#define WORLD_H

extern int world( int i, float j);

#endif

main.cpp:

extern "C"
{
#include "hello.h"
#include "world.h"
}

int main()
{
    int (* pFoo) (int, float);
    pFoo=hello;
    pFoo(1,0.2);

    pFoo=world;
    pFoo(1,0.2);
    return 0;
}

compilation et exécution:

$ gcc hello.c -shared -fPIC -o libhello.so
$ gcc world.c -shared -fPIC -o libworld.so
$ clang++ -L/tmp/tmp -o test main.cpp -lhello -lworld
$ LD_LIBRARY_PATH=./ ./test
hello 
world!

La même technique résout-elle ton problème? (j'ai utilisé Clang++ et non G++ pour le C++ pour le fun, en théorie ça ne change rien, c'était histoire d'utiliser 2 compilo, mais bon ils sont compatibles donc… mais j'ai rien d'autre sous la main.)

En tout cas, ce PoC marche, si ton cas ne marche pas, encore une fois, poste un extrait de code, qu'on puisse te répondre sans être dans le brouillard.

tu ne te considères plus avancé que le béotien

Je ne me considère plus comme un débutant total, mais je reste loin d'être bon, encore trop à apprendre.

Ne le prend pas mal

Si je devais prendre mal des commentaires constructifs, je serait vraiment bête :) au contraire, je te remercie de prendre le temps.
Et si je prenais mal un commentaire sur internet, je n'irai pas sur LinuxFR xD (parce qu'il faut avouer que ça balance quand même assez sévère parfois)

Le RAII est apparu pour résoudre un problème introduit par les exceptions.

Je ne sais pas pourquoi c'est apparu, mais c'est également utile dans un code qui n'utilise pas les exceptions. Par exemple, quand on utilise une lib C, disons, SDL, pouvoir s'abstenir d'allouer et désallouer manuellement la mémoire à chaque fois que l'on rencontre une erreur est utile.
Je vois plutôt la RAII comme une alternative aux GC, qui à l'avantage de permettre quand on ne se sert plus d'un objet de libérer les ressources qu'il utilisait immédiatement, comme une connexion, chose qui est faite avec une latence dans le cas d'un GC (puisqu'il ne passe pas en permanence derrière le programme, si je ne m'abuse).

La façon dont c'est fait en C++ apporte trop de désavantages

Je viens de regarder la section pointée, et il apparaît que la plupart des inconvénients cités soient liés aux éditeurs de textes et compilateurs, le reste étant un problème de temps de compilation (il faudrait ajouter que dans le cas d'une lib proprio, on ne peut pas masquer le code j'imagine).

Des langages comme Ada

ADA m'intéresse, mais la dernière fois que j'ai essayé de m'y mettre, je n'ai pas réussi à trouver de doc satisfaisante pour mettre le pied dedans.

Les fonctions inline existent aussi en C depuis le C99 (15 ans !!!).

Ok mea culpa.

C'est un des plus grands problèmes du c++, amha. On a ajouté, ajouté et encore ajouté.

Je suis d'accord, mais il me semble qu'ils invoquent la compatibilité avec le C comme excuse, en voulant l'enrichir, ce qui rend je pense l'ensemble plus complexe.
S'il cassaient la compatibilité avec le C, tout en gardant le fait d'être compilé et de ne pas avoir de GC, ça rendrait peut-être C++ (ou le langage qui en résulterait) plus gérable.

Par exemple, pourquoi n'y a-t-il pas une construction W pour construire du sucre syntaxique ?

Effectivement, c'est quelque chose qui serait vraiment agréable. D'ailleurs, je suppose que ça m'aurait évité de commettre l'erreur plus haut, puisque j'avais fait ça dans le but de construire justement une syntaxe pour éviter de se fader du boilerplate à n'en plus finir… Je n'ai pas (encore) regardé l'article que tu cites, mais je pense avoir compris l'idée?

Je pense que je n'avais pas ajouté de simples parenthèses, en fait. La mémoire… ça remonte ce truc :)

Me semble qu'en fait, j'avais lu quelque part que, dans le cas ou les paramètres contiennent des appels à des fonctions, alors ces fonctions sont évaluées dans l'ordre, que la fonction soit inlinée ou pas, et j'avais donc utilisé cette méthode (je ne sais pas pourquoi j'ai pensé aux parenthèses, l'autre jour, mais bon, c'est un code d'il y à 2 ans et impliquant un langage que je préférerait oublier). Le résultat est alors devenu cohérent sur les 2 compilateurs que j'utilisais: G++ (quoique j'utilisais peut-être déjà clang++, je ne sais plus) sous Debian testing, et visual studio 2008 (je sais, c'est un IDE, mais je connais pas le nom du compilo sous jacent).

Franchement, d'ordinaire, je ne me serais pas amusé à faire ce genre de trucs casse-gueule, de la même façon que d'habitude, j'évite les macros comme la peste. Dans le cas que j'ai cité, j'ai utilisé de façon assez massive des macros, et en un endroit cette chose, en combinaison avec des macros qui résultaient en ces fameux appels, justement.
L'idée était relativement simple (tout ce que je dis est un souvenir d'il y à 2 ans, je préviens. Depuis, j'ai dormi pas mal…):

Le langage powerbuilder se base sur une sorte de machine virtuelle, de la même façon que Java, et expose une API C++ assez mal fichue selon moi à l'époque (bien que maintenant je comprenne un peu plus les raisons, mais je pense toujours que c'est améliorable).
Cette API permets, malgré tout, de pouvoir "injecter" du code: ajouter des classes, en fait, appelables ensuite depuis un programme PB classique comme si les classes en question étaient codées en PB.
Par contre, côté code natif, c'était assez pénible: des chaînes de caractère à passer 3 fois à divers moments de l'init, une visibilité nulle quant à pourquoi le code sigsegv, et pour récupérer les valeurs reçues lors d'un appel d'une méthode par PB, il fallait écrire, pour chaque argument, un truc de ce genre (dans le genre, donc pas exactement, j'ai un très gros doute pour le type): "pbvm->arg(5)->get_int(x);" et bien sûr, ça pouvait encore planter parce que si on se trompait de type, ça crashait sans dire pourquoi, lors de l'appel par la pbvm.
Donc, j'avais fait une surcouche à cette API, qui permettait de pouvoir injecter des classes en faisant dans une classe "proxy" (le terme n'est pas exact) un simple héritage d'une part d'une classe de ma surcouche, et d'autre part de la classe C++ qui fait réellement le boulot (histoire de pouvoir vérifier sur une plate-forme non windows que ça compile/marche, sans avoir besoin de devoir accéder à la PBNI --l'API powerbuilder-- ).
Dans cette classe proxy, au début, il fallait au minimum autant de lignes de code par méthode que d'arguments powerbuilder, ce qui était lourd et générateur d'erreur.
Donc, vu que j'avais un peu de temps, j'ai essayé (et réussi, même si je n'était pas vraiment très fier de la propreté du code de cette partie de ma surcouche) de faire une sorte de langage basé sur les macros du C qui permette de réduire tout le boilerplate de chaque méthode rendue accessible à 1 ligne: la ligne de déclaration de boilerplate.

Genre:

#include "npbni.hpp" // ma surcouche
#include "foo.hpp" // la classe qui fait le véritable taf

class pb_foo : public foo, public npbni<NON_VISUAL_PNBI> // on pouvait exporter 2 types de classes, à la mécanique sous-jacente légèrement différente, donc template pour pas que ce soit trop pénible
{
RETURN_INT foo( TYPE_FLOAT, TYPE_INT, TYPE_STRING );
};

Je ne me souviens pas exactement des noms et du fonctionnement des macros, c'est juste pour donner un ordre d'idée.

C'est bien d'avoir de la RAM, oui, c'est sûr.

Maintenant, il n'y à pas que la taille^W capacité qui compte, mais aussi la fréquence. Je me demande si l'accès à la RAM d'un téléphone est aussi rapide que celui à celle d'un PC portable?

Mais on sait pourquoi.

La raison de ne plus utiliser les primitives de X, c'est qu'on veut des coins arrondis, de la transparence, et accessoirement utiliser le GPU pour ça (ce dernier point étant quand même pertinent).
Tout ça, ça implique d'utiliser OpenGL, et donc balancer des buffers pré-calculés au serveur graphique qui se contente de filer les pointeurs au GPU plutôt que de copier N fois ces fameux buffers résulte en simplification du code et amélioration des performances.

En fait, si on pouvait faire un toolkit qui utiliserait l'accélération 2D de Xorg, on pourrait avoir un truc réellement rapide sur le réseau, par contre, qui serait prêt, à l'heure actuelle, à se passer de toutes ces petites icônes, images & co hyper dures à compresser et gourmandes en BP? Qui serait prêt à se passer, en fait, de l'esthétique? (perso, ça me poserait aucun souci vu que je le fais déjà, mais je pense que je fais partie d'une minorité)

En gros, le pourquoi, c'est parce qu'on veut des trucs jolis, adaptés au rendu moderne, alors que X à été conçu à une époque ou l'efficacité primait sur le bling-bling (pour des raisons techniques, notamment).

Maintenant, je viens de me souvenir que, au moins OpenGL 1 (obsolète, je le rappelle) utilise une sorte de pile pour générer l'image. Je ne sais pas (mais alors vraiment pas, je m'y suis intéressé et ai abandonné quand il à été question de tesselation, d'autant que je me suis aperçu un peu trop tard qu'OpenGL 1 était… obsolète, snif, et que je n'ai rien trouvé de clair pour commencer à utiliser ces p***** de shader) s'il serait possible d'imaginer une transparence réseau ou l'appli envoie ce stack sur le réseau, et le PC client le reconstruit… peut-être que ça prendrai moins de BP?

Pas du tout. C'est effectivement possible mais ça reste une opération manuelle.

Bah après, il m'a dit que ça s'était fait tout seul, et je doute qu'il m'ait menti (pour ce que j'en ai à foutre de son windows… et il le sait très bien). Enfin, peu m'importe, les errements des trucs tout jolis qui te bouffent 1 à 2 Go de ram au boot m'intéressent moyennent, j'ai l'intention de rendre mes machines de plus en plus fonctionnelles (de mon point de vue, qui est que la souris est un instrument qui me consomme pas mal de temps de façon régulièrement injustifiée), pas de plus en plus jolies.

Les mainteneurs Debian peuvent très bien le faire avec leurs machines persos. Et franchement, 4Go de RAM, c'est peut-être l'entrée de gamme, mais sérieux, c'est déjà énorme, il n'y à que les super grosses applications qui peuvent bouffer tant à la compilation, et j'ai envie de dire que je ne suis pas sûr que ce soit toujours justifié.

Bon, il faut aussi dire que compiler avec GCC ne doit pas aider, c'est un véritable goinfre ce compilo, et j'ai constaté une diminution drastique de la RAM utilisée en utilisant clang il y à 2 ans (un projet qui faisait swapper à la compilation mon netbook et son unique Go de RAM avec 3 thread me laissait 200Mo utilisables avec clang et 4 thread).

L'ancienne interface (celle d'il y à 1 an) était mieux foutue sur ce point.

Par contre, je ne supporte absolument pas github, (je n'y vais que quand j'y suis contraint) pour diverses raisons, par exemple:

• interface bordélique
• interface lente
• interface inutilisable sans JS

Donc, même si bitbucket n'est pas à la mode, ça reste à l'heure actuelle mon favori. Quitte à avoir une usine à gaz comme github, autant utiliser sourceforge qui offre plus de fonctionnalités (forums, entres autres) et les trucs basés sur savannah semblent figés (bon, on attend mes patchs en même temps).

Accessoirement, bitbucket permets d'avoir 5 dépôt privés, utiles pour des trucs qui n'ont pas d'intérêt pour les autres mais qu'on peut améliorer par pichenette, genre un CV, des config de $HOME, voire pourquoi pas un projet fermé (et la, je prend le risque de me faire pourrir xD).

C'est un peu le béaba du c/c++.

Désolé, je n'ai jamais lu le standard, donc non, pas spécialement le b-a-ba. Oui, je sais que c'était un problème dans mon code, et, si, mon workaround avait résolu le problème. Je ne suis juste plus sûr que c'était exactement ça, peut-être que c'était une fonction inline. Mais c'est sûr que c'était un truc crade, par contre.

Encore une fois, si tu cherches un truc genre i3, tu t'es trompé d'OS.

Bof, je ne l'utilise pas personnellement, je ne fais que constater les ravages autour de moi. Comme je le dis dans un commentaire un poil plus haut, sur une machine vendue avec w8, ça rame de manière affolante, et je n'ai pas vu énormément de soft lancés au boot.
Alors, est-ce moi qui me plante d'OS, ou les constructeurs?

(mais la courbe d'apprentissage comme disent les anglo-saxons est assez frustrante).

Elle l'est moins quand on utilise les raccourcis clavier depuis longtemps, c'est comme ça que j'ai pu montrer comment imprimer à ma mère, notamment. Ils ont eu la décence de pas tous les changer…

C'est surtout tactile-oriented.

Je suis d'accord. Ce n'est donc pas une innovation du bureau puisque le bureau, c'est clavier+périphérique de pointage, pas écran tactile.
D'ailleurs, il semble que maintenant w8 boote sur l'interface classique. Il y a du y avoir une MaJ… (vu chez le frangin)

Hum. Que veux-tu dire par API asynchrone dans ce modèle?
Pour ce qui est de sandbox, j'ai du mal à voir pourquoi ce serait le taf d'un gestionnaire de fenêtre, ça devrait être celui du serveur graphique ou du kernel, non?
Ce sont de vraies questions, pas polémiques (la polémique viens de suite t'inquiètes ;) )

Et pour ce qui est de l'économie de batterie… quand je vois les "performances" de windows 8, je me permets de douter. Je suis allé chez mon frère il y à quelques temps, discuter, et tester HOM&M 6. Bon, que le jeu lui-même galère, c'était pas surprenant.
Mais on à du rebooter pour "nettoyer" la RAM, manifestement les choses ne semblent pas se fermer (selon mon frère) quand on le leur demande.
Les reboots ont bien mis 10 minutes chacun, sur une machine pourtant de moins d'un an, et sur laquelle je n'ai pas constaté de profusion de machins à la con lancés au boot.
Je doute que la batterie tienne bien longtemps sur un OS qui semble aussi chargé.

Alors la nouvelle efficacité du paradigme, je suis assez curieux que tu en dises plus pour le coup, parce qu'avec mon truc ancestral, sur un netbook ben j'en ai pour 30s de boot, moi, et la batterie tenait ses 6 heures d'utilisation vidéo au début.
Et côté ergonomique, c'est une tuerie, modern UI. Dans le mauvais sens du terme, clairement, et pas que selon moi, qui au fond s'en cogne parce que je n'ai pas l'obligation de l'utiliser pour le moment. Et bien sûr, je prie pour qu'il en soit ainsi pour les siècles des siècles (enfin, si je vis encore ^)…

Quant au visuel… non, ce n'est pas "que" le visuel, c'est aussi le contrôle que l'on à sur les fenêtres, et le fait que les fenêtres se placent ou on le souhaite, d'elles-même. Mais, je t'accorde qu'avec certaines applications, c'est pénible, notamment xpaint, gimp en mode multi-fenêtre (ce qui n'est plus obligatoire du coup) et celles qui s'amusent à utiliser des boîtes de dialogue en popup.
D'où très certainement mon attirance relativement récente pour les applications TUI :) en plus, ces applications dans le cas de celles qui sont en ligne de commande s'interface magnifiquement avec les autres, il suffit de piper.

Au sujet de Lennart… je n'ai pas d'opinion, je suis trop nouveau dans l'utilisation de Linux. Je sais ce qui lui est reproché, mais… bah, il à des idées différentes, et les moyens de les implémenter, alors qu'il fasse. S'il faisait vraiment que de la merde, je doute qu'il serait embauché chez Red Hat d'une part, et d'autre part que des distros autres que RHEL et Fedora utiliseraient ses œuvres.
Tu ne me verras pas critiquer un de ses softs à cause de l'auteur, je pense, pas d'ici longtemps. Surtout que je pense sincèrement que des choses comme systemd sont intéressantes, parce qu'elles vont faciliter le contrôle des débutants sur leurs machines. Maintenant, le fait que moi je préfère éviter est pour une autre raison, et c'est pas l'amour de sysvinit, juste que je ne vois pas l'avantage de systemd compte tenu de mon utilisation des dites machines, et que je considère que les divers composants de systemd sont trop inter-dépendants. Maintenant, des applications non portables, il en existe plein, on a jamais tué personne pour ça, il suffit d'en utiliser une autre, mais généralement les autres ont moins de fonctionnalités. C'est une histoire de compromis tout ça.

Oui, bien sûr et heureusement que la modularité est faisable en électronique, sinon on serait tous avec des powerPC à l'heure actuelle, parce qu'IBM/Microsoft n'auraient pas réussi à s'imposer (archi matérielle ouverte, donc machines améliorables par la greffe de composants faits par des tiers, donc réduction des coûts, contrairement aux mac du début, si je ne m'abuse).

Maintenant, je répondais à un commentaire qui disait "si ce n'est que le hardware, il n'y a qu'à le faire". J'ai vu des projets qui essaient de faire des cartes graphiques, d'autres des consoles, et je suis aussi tombé sur des explications pour faire son propre smartphone. Franchement, si quelqu'un sort le-dit smartphone dans la rue, il a intérêt à savoir assumer sa différence, parce qu'on ne parle plus de frigo, mais de congélo industriel à ce niveau la :)

Et dans le cas où l'on veut faire tout le matos en libre, il faut effectivement repartir de zéro, parce que je doute qu'il y ait des composants industrialisés qui soient déjà libres au sens des 4 libertés de RMS ou des DFSG. Quelques interfaces et protocoles, oui, mais le matos proprement dit? M'étonnerait malheureusement.

Et au sujet d'apple, il y à une époque ou ils faisaient tout, de A à Z je crois. Ils ont fini par abandonner pour réduire un peu le coût, et passer d'objets pro à objets de luxe. Maintenant, ils utilisent une archi intel (pour la déclinaison bureau, je parle, hein), comme la plupart des autres j'imagine. En tout cas, jamais vu d'autres archi que de l'x86 sur un PC de bureau.

J'ai plutôt l'impression que la cause d'emmerdes majeures des packageurs, c'est la quasi absence de préoccupation du packaging des dev de KDE (et peut-être des gros projets de manière générale?):

• pas de version stable, chaque nouvelle version ajoute de nouvelles fonctionnalités, et donc bugs
• archives monolithiques même si les sources que ça inclue sont relatives à plusieurs modules distincts

Et un commentaire intéressant du mainteneur Debian:

Not so far ago, discussing something with some upstream (not Qt), he told me "just make -j6 upload and be done". My first reaction was "I wish I could do that". My "most capable" system is a dual core with "just" 4GB of RAM, so I have to resort to swap for being able to build beasts like webkit.

Bon, à priori il y a aussi des problèmes de communication entre les mainteneurs des diverses distro, qu'ils semblent avoir envie de résoudre d'ailleurs…

A noter que certains mainteneurs parlent de problèmes liés au fait que gnome et kde utilisent des versions incompatibles des mêmes lib. Ça, je trouve ça vraiment très, très drôle (je doute que ce soit leur cas, m'enfin…)

Sinon, le seul commentaire au sujet de ffmpeg dans cette discussion, c'est pour dire qu'a cause de problème de licence, c'est plus casse-pied que gstreamer, je n'ai rien noté sur le plan technique.

Tout ceci étant dit, ce sujet est intéressant (celui qui est pointé) pour ceux qui ne comprennent pas vraiment les différences entre les distros (comme moi): pour le coup, vu qu'ils parlent des problèmes et des solutions apportés par les divers systèmes de paquet, je vais enfin pouvoir y voir un poil plus clair dans cette jungle.