La moralité je m'en branle (tout comme toi je pense).
Ce qui (me) chiffonne c'est cette volonté d'imposer des standards que vous mêmes vous ne respectez pas. Il y a des règles du jeu, et tout le monde est prier de les respecter, que cela soit des gens qui ne font que +4% comme vous que pour des gens qui font +12% comme redhat.
Sur l'acpi (j'aime rester concis) vous avez non seulement le meilleur cheval, mais en plus toute la course. Alors c'est quoi l'intérêt de pourrir la vie aux autres ? Les constructeurs ? hummm non je connais bien fujitsu (ils prolongent le support matériel redhat sur 18 mois), et ce qu'ils implémentent niveau bios ne vient pas d'eux... (pourtant on a bien un menu "linux" dans le bios chez eux depuis 2 ans)
Bref je ne te reproches rien (c'est le mode évidence), juste s'il te plait reste honnete avec les gens honnetes.
Non mais est ce que tu te rends compte si une telle politique était appliquée ) des avions ou des trains ?
L'avantage commercial et technologique vous l'avez sur ce sujet, pourquoi en plus fournir du bug ? vous n'êtes pas à l'aise dans vos baskets ou quoi ?
Heu, rectification nécessaire. Ils ont crée acpi (et suivant) et cela fu accepter par simpliciter (car c'était beau). OK. Maintenant venir accusé les autres de vouloir coller au standard de fait, lorsque ce standard de fait est fourré de bugs (à croire que c'est fait exprés, mais là encore tu en sais plus que moi sur les tables pourries qui nécessitent des correctifs non diffusés avant). Bref ils n'assument pas d'avoir créer un standard.
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.
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 :(
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.
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" :)
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".
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 ?
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
[^] # Re: Android : basé sur Linux, (+/-) libre, gratuit, et pourtant ...
Posté par bubar🦥 (Mastodon) . En réponse au journal 44% des Smartphones vendus aux USA utilisent Android. Évalué à 2.
je ne suis rien d'autre qu'un utilisateur avant tout et finalement
désolé s'il y a eu confusion
[^] # Re: Android : basé sur Linux, (+/-) libre, gratuit, et pourtant ...
Posté par bubar🦥 (Mastodon) . En réponse au journal 44% des Smartphones vendus aux USA utilisent Android. Évalué à 4.
Ce qui (me) chiffonne c'est cette volonté d'imposer des standards que vous mêmes vous ne respectez pas. Il y a des règles du jeu, et tout le monde est prier de les respecter, que cela soit des gens qui ne font que +4% comme vous que pour des gens qui font +12% comme redhat.
Sur l'acpi (j'aime rester concis) vous avez non seulement le meilleur cheval, mais en plus toute la course. Alors c'est quoi l'intérêt de pourrir la vie aux autres ? Les constructeurs ? hummm non je connais bien fujitsu (ils prolongent le support matériel redhat sur 18 mois), et ce qu'ils implémentent niveau bios ne vient pas d'eux... (pourtant on a bien un menu "linux" dans le bios chez eux depuis 2 ans)
Bref je ne te reproches rien (c'est le mode évidence), juste s'il te plait reste honnete avec les gens honnetes.
[^] # Re: Android : basé sur Linux, (+/-) libre, gratuit, et pourtant ...
Posté par bubar🦥 (Mastodon) . En réponse au journal 44% des Smartphones vendus aux USA utilisent Android. Évalué à 4.
L'avantage commercial et technologique vous l'avez sur ce sujet, pourquoi en plus fournir du bug ? vous n'êtes pas à l'aise dans vos baskets ou quoi ?
[^] # Re: Android : basé sur Linux, (+/-) libre, gratuit, et pourtant ...
Posté par bubar🦥 (Mastodon) . En réponse au journal 44% des Smartphones vendus aux USA utilisent Android. Évalué à 2.
[^] # Re: Et dans 6 mois..
Posté par bubar🦥 (Mastodon) . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 2.
[^] # Re: faut arrêter de s'accaparer le projet fait par les autres
Posté par bubar🦥 (Mastodon) . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 5.
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.
# chromium / chrome
Posté par bubar🦥 (Mastodon) . En réponse au message problème de connexion avec hotspot Neuf (distro rpm based). Évalué à 3.
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.
[^] # Re: interface
Posté par bubar🦥 (Mastodon) . En réponse à la dépêche Ordissimo sort un nouveau système. Évalué à 2.
[^] # Re: Et dans 6 mois..
Posté par bubar🦥 (Mastodon) . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 2.
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 :(
[^] # Re: Et dans 6 mois..
Posté par bubar🦥 (Mastodon) . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 4.
[^] # Re: faut arrêter de s'accaparer le projet fait par les autres
Posté par bubar🦥 (Mastodon) . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 2.
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.
[^] # Re: part de marché ?
Posté par bubar🦥 (Mastodon) . En réponse au journal Xserve. Évalué à 3.
[^] # Re: Mauvais site
Posté par bubar🦥 (Mastodon) . En réponse au journal Xserve. Évalué à 10.
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...
[^] # Re: faut arrêter de s'accaparer le projet fait par les autres
Posté par bubar🦥 (Mastodon) . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 2.
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.
[^] # Re: Et dans 6 mois..
Posté par bubar🦥 (Mastodon) . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 2.
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 ? ;-)
[^] # Re: faut arrêter de s'accaparer le projet fait par les autres
Posté par bubar🦥 (Mastodon) . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 1.
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 :-)
[^] # Re: faut arrêter de s'accaparer le projet fait par les autres
Posté par bubar🦥 (Mastodon) . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 3.
"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 )
[^] # Re: faut arrêter de s'accaparer le projet fait par les autres
Posté par bubar🦥 (Mastodon) . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 4.
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.
[^] # Re: Et dans 6 mois..
Posté par bubar🦥 (Mastodon) . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 3.
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 ;-)
[^] # Re: Pas de transparence réseau ?
Posté par bubar🦥 (Mastodon) . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 3.
Le développeur a pris cette solution là afin qu'on puisse tester facilement WayLand lors des premières releases grand public.
[^] # Re: Et dans 6 mois..
Posté par bubar🦥 (Mastodon) . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 5.
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....
[^] # Re: Et dans 6 mois..
Posté par bubar🦥 (Mastodon) . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 2.
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.
[^] # Re: Pas de transparence réseau ?
Posté par bubar🦥 (Mastodon) . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 3.
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 ?
[^] # Re: Fichier caché par un montage ?
Posté par bubar🦥 (Mastodon) . En réponse au message Où est utilisé mon espace disque ?. Évalué à 2.
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
[^] # Re: Fichier caché par un montage ?
Posté par bubar🦥 (Mastodon) . En réponse au message Où est utilisé mon espace disque ?. Évalué à 2.