bubar🦥 a écrit 6975 commentaires

Ce n'est pas compliqué, c'est juste mal intégré (à part sur Fedora). Et au delà de l'intégration, c'est juste pas mieux qu'ailleurs, alors que ça pourrait l'être.

Une petite mise en perspective, en reprenant ce que tu as dit avant.

C'est là, normalement, que le rôle des distributions serait majeur : proposer l'intégration de briques éprouvées. C'est également là la limite du "tout en amont", pour quiconque n'en ayant pas vraiment les moyens.

Que KDE n'ai pas les moyens de maintenir la branche 3 pendant le développement de la branche 4 est regrettable, certes. Mais qu'ils sclérosent leur projet pour répondre à ce besoin de marché est un non-sens. Le projet, celui ci ou un autre, doit avancer. L'évolution est plus importante pour eux, et pour les utilisateurs à terme, que le maintien. Ce rôle devrait être dévolu aux distributions.

C'est ce que fait Debian.
C'est également ce que fait Redhat. (en faisant bien le distingo fedora/redhat...)

Pour les autres distributions, c'est bien plus difficile de le réaliser. Elles ont souvent fait le choix de céder aux sirènes des utilisateurs. Ces derniers, contrairement au "marché du proprio" est au courant que machin-version-x vient de "sortir" et n'admet pas toujours que la version-x n'est pas encore faite pour lui. Ce flou est parfois nécessaire afin de montrer que contrairement au marché proprio il est possible aussi de prendre cet escalier... Important parfois de proposer du "bleeding edge" sens développeurs aux utilisateurs afin d'avoir une masse de retour suffisante. C'est là que des distributions comme Fedora, et unstable chez Debian, entrent en jeu.

Tu le sais tout ça, depuis + longtemps que moi.

C'est donc là où je rejoins tes propos sur les distributions "mostly useless". Celles qui font croire que c'est stable et qu'elle sont destinées au grand public alors que cela ne peux pas être le cas. Elles se gourrent (volontairement ou pas, j'en sais rien) et entretiennent la confusion entre "pour mr michu" et "pour contrib". Parfois en bien, car ainsi elle participe parfois à augmenter la masse de retours pour le projet en amont. Mais elles le font au détriment de leur coeur de cible déclaré.

Bref, si le manque de moyens est un élément fondamental, force est de constater que cela avance quant même (pas assez vite au goût de certains), et cela avance en terme de fonctionnalités et de qualité. Ce n'est pas la seule variable d'ajustement, donc.

A noter que Ubuntu a choisi un chemin légèrement différent : celui de proposer leurs développements finaux basés sur des briques existantes. Canonical n'ayant pas les moyens d'être "tout en amont" encore aujourd'hui, ils ont trouvés là une bonne méthode pour ne pas blesser leur utilisateurs michu : Ils n'entendront jamais "gnome shell de gnome 3 c'est pourri" car ils évitent soigeneusement cette délicate étape à leur utilisateurs. Bref un chemin différent de Debian et Fedora, mais parfaitement adapté à ce qu'ils peuvent faire, concrêtement, aujourdh'ui.

Si on écoute trop les développeurs, on atteinds jamais "la maturité" : il reste toujours à faire.
Si on écoute trop les utilisateurs, on prends toujours une version instable car ils savent que version-x est "sortie".

Bref, il manque une volonté affichée de la part d'une distribution grand public de dire "ok on fige et on maintien". J'ai jamais vu un client raler après Redhat parceque son Gnome était un peu vieillot ... Il est stable, maintenu, sécurisé. Et les updates matériels, ce qui est réellement important, sont réalisés.

C'est le rubicon du logiciel libre :
Comment proposer du réellement michu-proof, tout en continuant d'être un tremplin, respectable et respecté, à contributions ? Redhat a répondu a cette question il y a longtemps, avec Fedora. A un moment où un autre il faudra bien se dire que l'évolution des contributeurs ne suivra plus l'évolution des utilisateurs en terme de nombre, et qu'il n'est pas possible de transformer tout utilisateur en contributeur. Canonical a trouvé sa réponse, en fonction de ses possibilités, aussi.
Même question, mais posée sous un autre angle : comment continuer à assurer une telle vitesse de développement et de déploiement tout en ayant une vraie politique de maintien, du point de vue système ?

En conclusion, manque de moyens, oui, certainement. Mais ce n'est pas en en mettant plus sur le développement qu'on trouvera une réponse. Cela c'est juste indispensable pour le développement lui même ("juste" ;) ). On aurait alors simplement plus de développements plus vite, mais toujours pas le maintien nécessaire à une distribution "michu proof". Enfin, KDE pour reprendre ton exemple, suit un rythme correctif actuellement. Il y a donc il me semble une fenêtre de tir commune entre projet et distribution, en ce moment.

Un O.S. comme navigateur, forcément ça fait même le café \o/

Installe un navigateur alternatif, afin que celui ci ne cherche pas à faire le café. Bref pour moi c'est pas un problème système, mais un problème avec le navigateur.

Pour qui ?

Mode évidence : je suis d'accord.
Si je fait des calculs simples : j'ai plus donner aux LL qu'à n'importe quel autre projet (même politique !!!!). Et pourtant j'ai un gros goût d'amertume lorsque je vois mon incapacité à faire plus. Bon, tu m'a décidé, lors de mon prochain taf, ça sera 10% pour les LL. Et au diable les distributions !!!

Au delà du "je je" pour forcer le trait sur l'aspect personnel, il y a c'est sûr un manque flagrant de soutien ! En terme de matos par exemple :(

ppdc : alsa

Je continue d'y croire, m'sieur. Darwin est encore plus important dans le logiciel libre que dans n'importe quelle autre couche du logiciel.

C'est juste que ce Darwin n'a pas encore rencontré le marché de michu...

Bon ça c'est pour l'aspect business un peu, parcequ'il ne faut pas oublier qu'une immense majorité code du libre en s'en branlant totalement du marché. Tant mieux.

Les seuls serveurs Apple que j'ai pu cotoyer dans le monde réel avaient été basculés sur FreeBSD. Pourtant par des Apple fans.

Juste, vous voulez pas arrêter avec ces journaux de Mac ?
Sans déconner, là je ne suis plus, et pourtant j'en encaisse quelque uns des degrés d'ironie. Juste il manque un http;//unixfr.org en fait...

Bon j'vais me créer plein de comptes juste pour pouvoir "plusser grave" ton commentaire. (nan j'déconne, private-joke)

T'inquiètes pas (trop) la LiFo va changer la donne (ça fait déjà un moment que c'est entamé). Un peu comme lorsque Linus avait dit quelque chose du genre "cela ne sera qu'un effet secondaire"... il est probable qu'on puisse appliquer la même maxime à pas mal de distros très rapidement.

s/jackmix/jackeq
raa je me gourre toujours entre les noms.

Idéalement, jackeq devrait être intégré à kmix/gnome-mixer, ainsi que la partie "connections" et "patchbay" de qjackctl. Et lorsqu'il est lancé, tout les flux se connectent sur lui automatiquement, en indépendants, unifiés sur la sortie déjà utilisée.

Encore plus idéalement, que PA puisse remplacer Jack, vu que c'est ce dernier qui a été intégré par défaut. Mais ça semble être comme une arlésienne ce truc là, un peu comme sa gestion "click ça marche" pour le bluetooth.

Bon bref, peu importe.
Fedora nous démontre qu'il est possible de tout fait cohabiter, de manière simple (clique ça marche), stable (!) afin d'avoir le meilleur des deux mondes, ensemble.

C'est difficile de se dire "ferme la, tu va encore chiffonner du monde". Surtout que j'ai pas trop les moyens d'aller chercher dans Dmix / Alsa, puisque c'est certainement à ce niveau qu'il pourrait y avoir des améliorations drastiques, en fait.

Mais bon, finalement on un truc un peu comme sous Windows : quelque chose qui marche bien par défaut (pulseaudio, bon ok bémol par sur tout). Et si on veux faire du "pro son", ben on colle Jack (tout comme steinberg a été obligé d'inventer asio). Dommage, on aurait pu avoir "asio" par défaut, ici, vu que c'est du libre "chez nous" :)

A quant Jack dans Ubuntu ? ;-)

A propos de Phoronix, ils viennent de mettre en ligne un article passionnant sur l'historique des performances :
http://www.phoronix.com/scan.php?page=article&item=linux(...)

conclusion rapide :
toujours plus sans jamais gréver les performances. :)

Article à dévorer sans modération :-)

C'est normal qu'il n'y ai pas de références à Redhat. Dès le départ, le développeur a clairement indiqué : "je travaille sur wayland à titre personnel, il s'agit d'un simple hobby".

"it's not a new X server, it's a tiny display server + compositing manager" Avait également servi de mise au point face aux articles de Phoronix et autres qui avaient immédiatement commencés "à monter sur leurs grands chevaux".

Zut les notes initiales lors de l'ouverture publique du dépôt GIT ont sautées :(
( http://cgit.freedesktop.org/~krh/wayland/tree/NOTES obligé de faire une référence à mon commentaire ici https://linuxfr.org//comments/982935.html#982935 )

Ben (pour moi) c'est fini, ça.
Ils font du boulot sur apparmor.
Et à côté ne cherche pas à influer sur Gnome.

Boulot sur AppArmor directement upstream. Très bien.
Et Unity, ils ont besoin d'un truc différent mais sans vouloir blesser Gnome, très bien aussi. ainsi Gnome continue ce qu'il souhaite, sans influence massive externe, et eux pourront mettre en plase Unity sans géner les autres.

Petit à petit ma vision de Canonical change. En bien.

Perso je configure Kde pour qu'il lance jackdbus en début de session, ça marche très bien (en fait kde lance un pré-script de configuration : lancement jackd puis sched_RR pour celui-ci : sale hack. Plus un groupe dédié [jackuser] et un dmix a la mimine).

Bref jack n'est pas conçu pour ça. "nous, on cherche juste" à forcer un peu le système pour obtenir une simplicité d'usage. Jack a des limitations génantes pour un "vrai usage desktop accepté" :
_ pas de reconfigurations à chaud (passer d'un mode "joujou internet" à un mode "boulot son" demande un arrêt puis re-démarrage du serveur : pas bien grave mais génant)
_ pas de gestion de plusieurs cartes son sur un seul serveur (là il faut du gros sale hack pour pouvoir faire joujou avec, ou alors avoir un très joli dmix :p)
_ donc pas de transport de son entre.
_ pas de politique re-routage à chaud facile (par exemple permettant d'avoir par défaut tout les flux audio dans jackmix lors du lancement a postériori de ce dernier, pourtant il sait faire...)
_ pas de gestion du flash

Bref, des points noirs qui ont fait pencher la balance ailleurs en matière de serveur de son. Mais c'est dommage (je trouve aussi) car devant ce qu'il apporte, cela semble bien peu.

La doc de Alsa et celle de Gentoo sont des mines d'informations ;-)

Ca a toujours été le cas.
Le développeur a pris cette solution là afin qu'on puisse tester facilement WayLand lors des premières releases grand public.

Jackd est juste meilleur que tout le reste.
Mais il reste encore un palliatif à des déficiences de Alsa.

Jackdbus (ré-écriture en c++) apporte de gros gains pour le bureau : stabilité améliorée (une appli qui ferme mal ses flux lors de sa fermeture n'impacte plus jackd : il devient "applis-nazes-proof". Le transport d'informations est détaché du flux audio. Il pousse dbus dans ses limites, et c'est peut être là que le bas blesse ?)

Bref, jackd et jackdbus sont vraiment à recommandés chaudement (voir Qjackctl ou encore l'interface Gtk pour Ladish) : c'est une killer-app. Avec Jack pas besoin de coller un sale boost sur le micro pour augmenter son volume d'entrée en le pourrissant de parasites ... non non on duplique le flux et ajoute ce flux en sortie ... Génial. Bref les exemples ne manquent pas pour donner encore aujourd'hui à Jackd des points que PA n'a jamais pû atteindre (pourtant il s'y est préparé : rtkit, mode daemon, haute prio par défaut...)

Bref, c'est quelque peu décousu comme post. Dire que Jackd est encore aujourd'hui la solution "professionnelle" est une vérité (reconnue et établie, voir les discussions entre le dev de pa et celui de jack). Donc que les distributions ne prennent pas le meilleur pour s'occuper de l'intégrer "michu ready" c'est dommage (je trouve). Ou alors, bien que criant "le libre" sur tout les toits, elles accordent une grande importance aux trucs proprio genre Flash ? A part ça, je ne vois toujours pas aujourd'hui l'intérêt de PulseAudio ???? Tout ce que fait PA avec des configs a se taper, jackd le fait aussi, avec des interfaces graphiques qui ramolissent le cerveau, même....

Mouhai comment être "contre" ton commentaire ?
Pas possible... ha ben si... justement PulseAudio a été réalisé pour simplifier la gestion du son sur le bureau. On est donc loin de l'objectif initial.

Bref, perso j'ai longtemps ralé sur pulseaudio en tant qu'utilisateur. Et aujourd'hui pour le configurer c'est plus compliqué que de se configurer à la mimine Dmix... Mais force est de constater que sur Fedora l'intégration est remarquable (sur 12 et 13). Dans tout les cas, ça fonctionne, et très bien. C'est même hallucinant (tiens un superlatif). Et pourtant franchement mes tests sont des tests de bourrins, mais y a rien à faire, sur Fedora c'est très bien. (Install : tout fonctionne. Ajout de Jack, mancement de plein d'appli jack : tout fonctionne encore et la latence de jack n'est pas impactée par pa, ce dernier continuant de donner un accès au son d'une vidéo flash... bref des tests de bourrin, y compris avec des softs connus pour être "tuant" à leur fermeture, genre Jost).
Ca marche et faut le reconnaitre.

Il me semble que c'est -justement- un des points forts de Wayland : être simple, faire une chose et la faire bien. Pour le réseau, on pourra utiliser NX (bien plus efficace que xdmcp), voir encore mieux : Spice (bien que conçu pour local-virtuel_local-réel, il devrait être intéressant à de nombreux points de vues pour cette utilisation là aussi. Entre autre la couche de transport du son...)

Bref les "workstations" et les "servers de session" continueront sans doute d'utliser Xdmcp parceque "c'est standard et ça marche partout". Mais Mme Michu aura NX, elle. Et les ubergeeks [parait il que c'est à la mode, comme mme michue?] aura Spice.

Donc le but n'est pas de remplacer Xorg, et c'est ce que l'auteur dit très clairement, et a toujours dit très clairement (on peux retrouver des dépêches et des infos sur linuxfr à ce sujet aussi).

Et je crois, je m'avance peut être là, qu'Ubuntu à raison de se pencher dessus sérieusement aujourd'hui. Le projet est assez mûr. (mode évidence : s'ils y participent aussi, bien sûr, l'esprit de la loi, toussa) et je ne pense pas qu'Ubuntu souhaite non plus remplacer Xorg. Mais plutôt avoir une alternatives sérieuse et simple pour du matériel spécifique (petit pc genre umpc, netbook, tablettes et autres) essentiellement construit avec du INTEL.

Bref, perso pour le moment, je trouve cela extra. (bon heu, normal, hein)
J'espère juste qu'ils feront comme pour apparmor, et s'y mettrons chez wayland (et pas wayland chez eux...). Mais après cela reste des suppositions et un jugement de valeurs (que j'essaie de plus en plus d'éviter). Stratégiquement, il me semble qu'ils ont raisons de vouloir coller plus prêt du matériel, et dans le même temps simplifier (mme michu n'a pas besoin de tout ce que xorg est capable de faire). Les dangers, de mon point de vue, étant ceux évoqués (prendre un truc tout prêt, ne pas contribuer, et se faire ses modifs dans son coin) plus haut d'une part, mais aussi l'éventuelle dispersion de force : à coller du monde sur wayland et à le faire utiliser par de nombreuses personnes, cela peut il nuire au développement de xorg ?

Exemple plus causant :

du -h /
34G
du -h /machin
10G

mount /dev/sda7 /machin
du -h /machin
4.0K
du -h /
34G

Soit la proposition de vérifier qu'avant de monter une partition spéciale pour lui, ccache n'est pas été utilisé et non nettoyé... et du coup contient un gros fatra oublié... Qui, éventuellement, pourrait être déplacé sur /dev/sda7... M'enfin bon maintenant que c'est en prod, tu ne devrais plus avoir besoin de ccache

C'est pourquoi il te proposes de vérifier dessous (et pas dedans). Démonte ccache et vérifie cela, dès fois qu'il y ai du ménage à faire ...

Commentaire obsolète. Désolé.
Ces pétards ont été rappelés pour destruction massive il y a déjà quelques année.

Des vrais pétards ? Tu rigoles ? des manhurins fabriqués sous licence beretta, en moins bien, moins solides et moins fiables ?
mouhahaha sur ce coup là, je dirais plutot "les pauvres"

Une excellente opération marketting, remarquablement orchestrée, instrumentée et relayée par les partenaires. Fameuse opération promotionnelle, pré-vente des boites à des prix intéressants (une personne de mon entourage à alors acheté trois licences Seven, puisque celà lui revenait au prix d'une seule, puis a patienter quelques temps avant d'avoir effectivement les livraisons en automne).

C'est aussi une bonne nouvelle car cela signifie que plus de gens sont sensibles au respect des licences.

Par contre cela n'enlève en rien l'ignoble politique imposée par la pratique commerciale et la eula (j'achète un pc : je paye une licence windows. Je ra-chète un pc, je paye une seconde fois pour le même produit, merci la licence. J'étudie dans une école ayant des accords avec Microsoft qui me permettent de bénéficier de versions de windows et d'une suite complète d'utilitaires gratuitement, mais j'achète un pc, et je paye la licence... Encore un exemple : les prix de licences pour les revendeurs diffèrent beaucoup trop et faussent le marché en privilégiant les gros fournisseurs [grandes surfaces par exemple] au détriment du commerce spécialisé [monteur / dépanneur local, par exemple].
Bref s'il y a du vrai, et du bon, cela ne remplace pas l'existant.
Tu le sais mieux que moi tout ça.

ps : pour Kde, sur le message au dessus. Pas plus tard que hier j'ai passé 20 mn devant Seven (sans y toucher). en 20 minutes, sur un Seven propre, bien configuré et correctement maintenu / utilisé : Nero lance une popup, pil au même moment une fenêtre du centre de configuration est demandée et s'affiche : paf le bureau freeze, plus moyen de rien faire, et il a mis plus de 40 secondes à s'apercevoir qu'il y avait un problème de politique de focus. Sur Seven, en 2010. Dingue. Donc, bon...

ps2 : je suis aussi assez d'accord sur le "qui emmerde les développeurs de logiciels proprio". Et à force de trop tirer sur la corde, on risque de se retrouver avec des systèmes moins libres que ce qu'il aurait pû être. A force de ne pas faciliter la tache aux dev de proprio, les distributions "grands publics" risquent de se voir dépasser par du linux bien moins libre. "Joli" paradoxe. Pourtant les softs proprio de qualité ne manquent pas : Guitar Pro, Renoise, EnergyXT, PianoTeq (!!), Antidote, etc etc...
[purée v'là que je suis d'accord avec PbPg, /me va prendre sa température]

Merci Baud pour les corrections apportées.