J'ai beau essaye j'y arrive pas avec Gnome c'est comme retenter d'utiliser Windows c'est totalement ... bizarre, pas logique, inconfigurable, impersonnalisable. Alors si on aime le preformate et que l'on considere que les distributions/bureaux ont tout le temps raisons ok pas de probleme mais moi je prefere un bureau de bases tres moyen (et encore sous pardus il y a des choix et pas trop mal fait des le depart) mais pouvoir tout personnalise exactement comme je le souhaite en deux coup de cuillere a pot et sans aller tripatouiller dans des trucs a regedit (oui oui je sais les cles sont documente mais bon je trouve ca anti-ergonomique au possible).
moi ce que je reproche c'est que c'est la seule distributions ou je suis incapable d'avoir mes propres versions de paquets python. Je suis oblige d'avoir celle du systeme. J'ai ete incapable d'installer le moindre paquet de facon correct alors que sur ubuntu/pardus/fedora je n'ai jamais eu le moindre probleme.
Kde 4.2 commencait a peine a etre utilisable KDE4.4 est plus que utilisable et d'ailleurs Gnome fait bien viellot a cote... Alors certes si tu rajoutes le gros hack compiz (qui n'est pas un projet Gnome donc c'est legerement triche mais je vais etre gentil et te l'accorder) cela fait "comme si" mais la realite est tout autre. KDE4, aujourd'hui, est mature, stable, robuste (pas eu un seul plantage depuis je ne sais pas quand), configurable...
Les debuts ont ete laborieux mais maintenant c'est du tout bon et sinon j'aimerai bien entendre les vrais critiques dessus (en dehors des histoires de gouts naturellement :) ) et puis c'est pas une honte que les devs bossent vraiment d'une version a l'autre et sur des choses reellement visibles pour l'utilisateurs.
A cause de la sortie prochaine de la nouvelle version stable
Juste une question legerement trollesque mais pas tant que cela malheureusement... c'est pour quand? Dans 1 mois ou dans 1 an?
Cela change pas mal de chose car si c'est 1 mois je veux bien comprendre mais si c'est dans un 1 an c'est completement ridicule.
Au passage KDE evolue tellement vite actuellement que entre kde 4.3 et 4.4 c'est vraiment un enorme difference qu'il y a, les defauts de jeunesse de kde4 sont quasiment tous elimine et on voit enfin apparaitre les nouvelles technos interessantes et surtout fonctionnelle tel que akonadi.
je pense qu'il te demandais de corriger ce que tu dis car il serait assez surprenant que l'on demande a un employe de Canonical de ne pas contribuer a Ubuntu...
git init
git add tonfichier
git commit -m "Que c'est difficile d'utiliser Git... en effet beaucoup plus que de creer un repository local"
Je trouve ca plus simple mais comme on dit chacun son truc ou donne moi en trois commande comment faire l'equivalent avec svn et je reviendrai peut etre sur mon jugement de ce systeme.
ps: tu peux remplacer git par mercurial ou bazaar cela marche en autant de commande.
Le probleme c'est que RH a decide d'utiliser PulseAudio et comme tout le monde (ou presque) suit ce que fait RH c'est mort pour le reste meme si techniquement c'est meilleur. Un peu comme avec Gnome, ils veulent un seul type de GUI pour la conf du coup KDE sous RH/Fedora est un gros truc batard.
Prouver quoi ? Mono est libre, et ses fesses sont assurés par OIN.
Aller si tu preferes je citerais Moonlight initie et developpe par la meme personne qui a lance Gnome et la c'est amusant mais les problemes de liberte l'embettent beaucoup moins... Donc je persiste c'etait bien un pretexte la licence de Qt.
D'ailleurs Moonlight a ete mis a l'index par ta distribs prefere.
Qtjambi c'est mort il me semble. Quand a pyside j'allais que le fait d'utiliser boost c'etait une mauvaise idee mais cela a ete recemment corrige d'apres leur webpage. Mais ca encore c'est une dilution des forces completement idiote...
c'est bien ce que je dis si les forces avaient ete mis sur GNUstep ou faire un equivalent libre de Qt comme cela avait ete demarre on aurait pas divise les forces en deux.
Qt est libre maintenant, mono est "libre" des attaques de Microsoft depuis tres recemment (et encore cela ne concerne meme pas l'integralite de mono il me semble donc situation du meme tonneau).
Qt/X11 a été disponible sous une licence libre à la même période ou GNOME présentait une version fonctionnelle donc voilà.
Gnome est fonctionnel? Depuis quand, la derniere fois que j'ai essaye c'etait pas le cas et c'etait il a une semaine
Plus serieusement il a fallu combien de personnes, de temps et d'argent pour arriver a un truc un peu fonctionnel par rapport a KDE? Je trouve effrayant la difference de moyen des deux et le peu de resultat de Gnome par rapport a KDE. En dehors de Opensuse et Mandriva il n'y a aucune distribution majeur derriere le projet contrairement a Gnome et encore Mandriva je ne suis plus sur que l'on puisse appeler ca encore distribution majeurs... (non ne me parlais pas de Kubuntu ca c'est de la deconstruction qu'ils font).
l'idee a l'air pas mal mais putain du perl... et que c'est @!#!$$!@# a installer sans etre root (en fait je n'y suis pas arrive mais je connais rien de rien a perl donc il doit y avoir une methode le probleme c'est laquelle...). Il y a aussi le fait qu'il faille changer un flag sur /tmp.
prétexte à quoi ? Qt n'était pas libre point barre, à l'époque, les gens avaient tenté de convaincre Trolltech de modifier la licence et/ou convaincre KDE d'utiliser autre chose.
Tu as oublie la partie sur GNUstep. Si il y avait eu une veritable logique c'etait pousse GNUstep pas creer un nouveau projet sur des fondations totalement batarde (Gimp Tool Kit).
Mono est libre, et ses fesses sont assurés par OIN.
À l'origine, c'est surtout que Qt était pas libre d'où la recherche d'une alternative libre (Gtk+).
Qui etait absolument pas prevu pour ce que cela a ete utilise au depart d'ou un joyeux merdier et des annees avant de voir sortir un truc du projet Gnome et en dehors de Gimp c'etait passablement minable...c'est rigolo car justement Gtk a l'epoque cela voulait dire Gimp Tool Kit... (je vous laisse juste verifier mes dires, installer une distrib a base de gnome1 et une avec KDE de la meme epoque vous allez pleurez).
Et par rapport a Qt pas libre c'etait juste un pretexte comme l'a prouve mono de plus a l'epoque le projet officiel etait GNUstep qui n'a jamais decolle par manque de developpeurs.
Cela me rappelle une expression d'ailleurs: "Diviser pour mieux regner"...
un bogue critique dans une version LTS (et qui aurait dû probablement être un release blocker)
Je vois pas pourquoi tu t'excites. La gestion des bugs par canonical/ubuntu est on ne peut plus connu. Par contre c'est aps plus mal qu'il l'ai rapporte a Fedora vu que Fedora doit sortir une version dans pas longtemps et que cette distrib est elle aussi touche.
En l'occurrence, ce n'est pas sur le seul Kees Cook qu'il faut taper, mais sur l'employeur qui ne lui permet pas de faire son boulot dans de bonnes conditions.
Et tu crois vraiment que cela va changer qq chose? La c'est juste Kees Cook qui se fait traiter d'incompetent etc donc a mon avis la prochaine fois il va se passer exactement ce que je decris c'est a dire rien. Le bug sera reference et "oh pas de bol on l'a pas vu". Cette facon d'agir est exactement la raison pour laquelle je me tape comme de ma premiere chemise des versions beta et RC (que ce soit ubuntu ou fedora d'ailleurs) car mon experience m'a montre que si un bug present et rapporte lors de la soit disant phase de test, sera present dans la version final. J'a l'impression que les devs corrigent uniquement les bugs sur lesquels ils tombent ou qui sont vraiment emmerdant comme une non harmonisation des couleurs dans le menu et j'exagere a peine c'est ca le pire. Alors ce n'est pas completement vrai pour Fedora mais uniquement parceque je connais personnellement le dev qui s'occupait des paquets qui me faisait c... Les distribs verifient en gros que les paquets s'installent comme il faut mais se moque un peu que le logiciel fonctionne ou pas.
D'autant que si on y regarde d'un peu plus près, il peut sembler un peu gros le bug, pour un système de fichier comme ext4 avec les pointures qui s'y sont collés
ce qui explique peut etre la reaction de T'so. Son amour propre aurait ete touche? :)
Je ne dis pas qu'il a tord mais bon la c'est un pauvre gars qui fait son boulot comme il peut qui s'en prend plein la tete. La communaute hors Ubuntu tape sur Canonical et dans Canonical le rapporteur de bug a du se faire tuer ce qui va l'inciter enormement a rapporter ce genre de bug ailleurs. La prochaine fois cela sent le bug qui va rester sur launchpad dans son coin bien au chaud. Alors certes cela criera parceque le bug avait ete decouvert sur Ubuntu et non passe aux autres mais que veux tu au moins il aura "juste" pas trie comme il faut le bug en question.
Donc sachant que le bug ne pourra pas etre reproduit sur une RHEL vu l'age du dernier kernel dessus et pas de ext4 il me semble, mettre le bug sur Fedora semble plus logique meme si il aurait du etre mis upstream. En meme temps upstream s'occupe plus specialement de 2.6.34 et celui en charge de la maintenance du noyau 2.6.32 aime Canonical autant que toi... donc bon le gars de Canonical a tente et je pense pas qu'il le refera.
De plus celui qui a pondu le bug n'est visiblement pas un specialiste des systemes de fichiers https://wiki.ubuntu.com/KeesCook alors qu'il demande de l'aide ailleurs c'est logique tout de meme surtout si il voit que le ailleurs a le meme probleme.
Cela n'enleve pas le fait que Canonical devrait avoir plus de monde sur le kernel et xorg.
ou tu le bouges si tu as un peu peur. Ce qui est amusant en faisant cela, comme cela m'a ete confirme dans un forum ou j'avais donne cette solution, c'est que c'est la seul method pour que ce logiciel ne prenne pas la main pour le son (la method officielle avec padevsuspender je crois n'est pas fonctionnel).
Red Hat != Fedora, ce n'est pas parce qu'un mec travaille chez RH, que forcément il bosse également sur Fedora (plus de 80% des contributeurs sont issus de la communauté).
Pour des question de kernel? J'ai comme un enorme doute sur le coup...
Par contre sur mainline je connais et je m'en moque, je suis passer a autre chose que ubuntu et non je ne suis pas passe a RH/Fedora car j'utilise KDE et RH/Fedora aime toujours pas ce bureau (cela m'enerve au plus au point d'avoir tous les outils de config clickodrome en Gtk).
[^] # Re: Adieu Mandriva
Posté par Albert_ . En réponse au journal Mandriva et Linagora. Évalué à 3.
J'ai beau essaye j'y arrive pas avec Gnome c'est comme retenter d'utiliser Windows c'est totalement ... bizarre, pas logique, inconfigurable, impersonnalisable. Alors si on aime le preformate et que l'on considere que les distributions/bureaux ont tout le temps raisons ok pas de probleme mais moi je prefere un bureau de bases tres moyen (et encore sous pardus il y a des choix et pas trop mal fait des le depart) mais pouvoir tout personnalise exactement comme je le souhaite en deux coup de cuillere a pot et sans aller tripatouiller dans des trucs a regedit (oui oui je sais les cles sont documente mais bon je trouve ca anti-ergonomique au possible).
[^] # Re: Adieu Mandriva
Posté par Albert_ . En réponse au journal Mandriva et Linagora. Évalué à 4.
[^] # Re: Adieu Mandriva
Posté par Albert_ . En réponse au journal Mandriva et Linagora. Évalué à 7.
Les debuts ont ete laborieux mais maintenant c'est du tout bon et sinon j'aimerai bien entendre les vrais critiques dessus (en dehors des histoires de gouts naturellement :) ) et puis c'est pas une honte que les devs bossent vraiment d'une version a l'autre et sur des choses reellement visibles pour l'utilisateurs.
[^] # Re: Adieu Mandriva
Posté par Albert_ . En réponse au journal Mandriva et Linagora. Évalué à 5.
Juste une question legerement trollesque mais pas tant que cela malheureusement... c'est pour quand? Dans 1 mois ou dans 1 an?
Cela change pas mal de chose car si c'est 1 mois je veux bien comprendre mais si c'est dans un 1 an c'est completement ridicule.
Au passage KDE evolue tellement vite actuellement que entre kde 4.3 et 4.4 c'est vraiment un enorme difference qu'il y a, les defauts de jeunesse de kde4 sont quasiment tous elimine et on voit enfin apparaitre les nouvelles technos interessantes et surtout fonctionnelle tel que akonadi.
[^] # Re: Adieu Mandriva
Posté par Albert_ . En réponse au journal Mandriva et Linagora. Évalué à 2.
[^] # Re: Adieu Mandriva
Posté par Albert_ . En réponse au journal Mandriva et Linagora. Évalué à 5.
il y a Opensuse et Pardus. Le reste c'est totalement batardise avec des outils de confs en Gtk.
[^] # Re: Comparaison avec Eclipse
Posté par Albert_ . En réponse à la dépêche Sortie de KDevelop 4.0. Évalué à 2.
git add tonfichier
git commit -m "Que c'est difficile d'utiliser Git... en effet beaucoup plus que de creer un repository local"
Je trouve ca plus simple mais comme on dit chacun son truc ou donne moi en trois commande comment faire l'equivalent avec svn et je reviendrai peut etre sur mon jugement de ce systeme.
ps: tu peux remplacer git par mercurial ou bazaar cela marche en autant de commande.
[^] # Re: Support d'autres formats ?
Posté par Albert_ . En réponse à la dépêche Une liseuse libre pour lire des livres libres. Évalué à 7.
ca a rien a voir. Tente de lire en plein soleil avec ton portable ou de faire un transatlantique en lisant un livre pendant presque tout le voygage.
[^] # Re: Tout ça ...
Posté par Albert_ . En réponse au journal Pulseaudio vs JACK. Évalué à 6.
[^] # Re: API ?
Posté par Albert_ . En réponse au journal Pulseaudio vs JACK. Évalué à 2.
[^] # Re: API ?
Posté par Albert_ . En réponse au journal Pulseaudio vs JACK. Évalué à 2.
Aller si tu preferes je citerais Moonlight initie et developpe par la meme personne qui a lance Gnome et la c'est amusant mais les problemes de liberte l'embettent beaucoup moins... Donc je persiste c'etait bien un pretexte la licence de Qt.
D'ailleurs Moonlight a ete mis a l'index par ta distribs prefere.
https://fedoraproject.org/wiki/ForbiddenItems#Moonlight
[^] # Re: API ?
Posté par Albert_ . En réponse au journal Pulseaudio vs JACK. Évalué à 2.
[^] # Re: API ?
Posté par Albert_ . En réponse au journal Pulseaudio vs JACK. Évalué à 2.
[^] # Re: API ?
Posté par Albert_ . En réponse au journal Pulseaudio vs JACK. Évalué à 4.
Tu en verrais si tu utilisais KDE4.4 :)
[^] # Re: API ?
Posté par Albert_ . En réponse au journal Pulseaudio vs JACK. Évalué à 2.
Qt est libre maintenant, mono est "libre" des attaques de Microsoft depuis tres recemment (et encore cela ne concerne meme pas l'integralite de mono il me semble donc situation du meme tonneau).
Qt/X11 a été disponible sous une licence libre à la même période ou GNOME présentait une version fonctionnelle donc voilà.
Gnome est fonctionnel? Depuis quand, la derniere fois que j'ai essaye c'etait pas le cas et c'etait il a une semaine
Plus serieusement il a fallu combien de personnes, de temps et d'argent pour arriver a un truc un peu fonctionnel par rapport a KDE? Je trouve effrayant la difference de moyen des deux et le peu de resultat de Gnome par rapport a KDE. En dehors de Opensuse et Mandriva il n'y a aucune distribution majeur derriere le projet contrairement a Gnome et encore Mandriva je ne suis plus sur que l'on puisse appeler ca encore distribution majeurs... (non ne me parlais pas de Kubuntu ca c'est de la deconstruction qu'ils font).
[^] # Re: Et la timeline ?
Posté par Albert_ . En réponse au journal Canonical FAIL. Évalué à 1.
[^] # Re: API ?
Posté par Albert_ . En réponse au journal Pulseaudio vs JACK. Évalué à 2.
Tu as oublie la partie sur GNUstep. Si il y avait eu une veritable logique c'etait pousse GNUstep pas creer un nouveau projet sur des fondations totalement batarde (Gimp Tool Kit).
Mono est libre, et ses fesses sont assurés par OIN.
Et Qt est libre.
[^] # Re: API ?
Posté par Albert_ . En réponse au journal Pulseaudio vs JACK. Évalué à 3.
Qui etait absolument pas prevu pour ce que cela a ete utilise au depart d'ou un joyeux merdier et des annees avant de voir sortir un truc du projet Gnome et en dehors de Gimp c'etait passablement minable...c'est rigolo car justement Gtk a l'epoque cela voulait dire Gimp Tool Kit... (je vous laisse juste verifier mes dires, installer une distrib a base de gnome1 et une avec KDE de la meme epoque vous allez pleurez).
Et par rapport a Qt pas libre c'etait juste un pretexte comme l'a prouve mono de plus a l'epoque le projet officiel etait GNUstep qui n'a jamais decolle par manque de developpeurs.
Cela me rappelle une expression d'ailleurs: "Diviser pour mieux regner"...
[^] # Re: Et la timeline ?
Posté par Albert_ . En réponse au journal Canonical FAIL. Évalué à 3.
Je vois pas pourquoi tu t'excites. La gestion des bugs par canonical/ubuntu est on ne peut plus connu. Par contre c'est aps plus mal qu'il l'ai rapporte a Fedora vu que Fedora doit sortir une version dans pas longtemps et que cette distrib est elle aussi touche.
En l'occurrence, ce n'est pas sur le seul Kees Cook qu'il faut taper, mais sur l'employeur qui ne lui permet pas de faire son boulot dans de bonnes conditions.
Et tu crois vraiment que cela va changer qq chose? La c'est juste Kees Cook qui se fait traiter d'incompetent etc donc a mon avis la prochaine fois il va se passer exactement ce que je decris c'est a dire rien. Le bug sera reference et "oh pas de bol on l'a pas vu". Cette facon d'agir est exactement la raison pour laquelle je me tape comme de ma premiere chemise des versions beta et RC (que ce soit ubuntu ou fedora d'ailleurs) car mon experience m'a montre que si un bug present et rapporte lors de la soit disant phase de test, sera present dans la version final. J'a l'impression que les devs corrigent uniquement les bugs sur lesquels ils tombent ou qui sont vraiment emmerdant comme une non harmonisation des couleurs dans le menu et j'exagere a peine c'est ca le pire. Alors ce n'est pas completement vrai pour Fedora mais uniquement parceque je connais personnellement le dev qui s'occupait des paquets qui me faisait c... Les distribs verifient en gros que les paquets s'installent comme il faut mais se moque un peu que le logiciel fonctionne ou pas.
[^] # Re: API ?
Posté par Albert_ . En réponse au journal Pulseaudio vs JACK. Évalué à 5.
[^] # Re: Et la timeline ?
Posté par Albert_ . En réponse au journal Canonical FAIL. Évalué à 4.
ce qui explique peut etre la reaction de T'so. Son amour propre aurait ete touche? :)
Je ne dis pas qu'il a tord mais bon la c'est un pauvre gars qui fait son boulot comme il peut qui s'en prend plein la tete. La communaute hors Ubuntu tape sur Canonical et dans Canonical le rapporteur de bug a du se faire tuer ce qui va l'inciter enormement a rapporter ce genre de bug ailleurs. La prochaine fois cela sent le bug qui va rester sur launchpad dans son coin bien au chaud. Alors certes cela criera parceque le bug avait ete decouvert sur Ubuntu et non passe aux autres mais que veux tu au moins il aura "juste" pas trie comme il faut le bug en question.
[^] # Re: Bof
Posté par Albert_ . En réponse au journal Canonical FAIL. Évalué à 5.
De plus celui qui a pondu le bug n'est visiblement pas un specialiste des systemes de fichiers https://wiki.ubuntu.com/KeesCook alors qu'il demande de l'aide ailleurs c'est logique tout de meme surtout si il voit que le ailleurs a le meme probleme.
Cela n'enleve pas le fait que Canonical devrait avoir plus de monde sur le kernel et xorg.
[^] # Re: API ?
Posté par Albert_ . En réponse au journal Pulseaudio vs JACK. Évalué à 2.
sudo rm /usr/bin/pulseaudio
ou tu le bouges si tu as un peu peur. Ce qui est amusant en faisant cela, comme cela m'a ete confirme dans un forum ou j'avais donne cette solution, c'est que c'est la seul method pour que ce logiciel ne prenne pas la main pour le son (la method officielle avec padevsuspender je crois n'est pas fonctionnel).
[^] # Re: Bof
Posté par Albert_ . En réponse au journal Canonical FAIL. Évalué à 2.
Pour des question de kernel? J'ai comme un enorme doute sur le coup...
[^] # Re: Et la timeline ?
Posté par Albert_ . En réponse au journal Canonical FAIL. Évalué à 3.
un lien interessant trouve dans le tiens :)
Par contre sur mainline je connais et je m'en moque, je suis passer a autre chose que ubuntu et non je ne suis pas passe a RH/Fedora car j'utilise KDE et RH/Fedora aime toujours pas ce bureau (cela m'enerve au plus au point d'avoir tous les outils de config clickodrome en Gtk).