Il n'y a pas besoin de barre de tâches, le but de GNOME Shell n'est pas de redévelopper GNOME autour de paradigmes vieux de 30 ans, mais de réinventer la façon dont on interagit avec sa machine. Si tu t'attends à retrouver ta barre de tâches, tu peux changer de bureau, il y a peu de chance que ça arrive.
C'est pas les mêmes cas d'utilisation, SQLite est une base de donnée embarquée alors que MySQL est un serveur de base de données.
SQLite est certes très simple à utiliser, et est extrêmement avantageux dans bon nombre de cas (base embarquée, prototypage etc ...), mais ne gère absolument la concurrence, ne passe pas à l'échelle (à partir d'un giga de données, il est futile de continuer à utiliser SQLite), ne gère pas les utilisateurs.
drizzle ne réponds pas aux même cahier des charges, il est optimisé pour la mise à l'échelle et les performances (d'où l'abandon de la couche moteurs de stockage), il supporte moins de types, pas de support du FTS (enfin, le support n'était pas non plus extra dans MySQL ou MariaDB), il utilise un nouveau protocole basé sur Google Protocol Buffers et n'est donc pas compatible avec les clients existants etc ...
MariaDB est un remplacement "drop-in" à MySQL (ce qui n'est pas sans poser de problèmes pour les distributions, du fait que les fichiers sont nommés de façon identiques), ça juste marche.
Ce problème a été mentionné par Colin Charles (employé de Monty Programs et auparavant par MySQL AB) lors de l'Open World Forum le week-end dernier et c'est effectivement un vrai problème.
Monty est en partie responsable de cette situation (il a choisi le modèle double-licence, il a vendu en toute connaissance de cause MySQL à Sun sans aucune garantie), donc au lieu de passer son temps à se plaindre, il ferait mieux d'agir. Il serait grand temps que MariaDB devienne un vrai fork de MySQL et arrête de jouer au jeu du chat et de la souris avec Oracle. Soit Oracle est un partenaire correct et on travaille avec lui, soit il ne l'est pas et on se casse définitivement (merci la GPL).
C'est une nouvelle neuve que de savoir qu'Oracle c'est gros vilains méchants pas beaux et qui sentent mauvais. Monty c'est guère mieux, c'est grippe-sou qui se plaint qu'on ne lui rende pas la pleine propriété de son bien sans contrepartie après l'avoir vendu au prix fort.
je résume:
* environ 20 Go de RAM
* jusqu'à au moins 250 Mo de RAM libre ==> soit moins de 2% de RAM libre
* swappiness à 15% c'est à dire si 85% de la RAM occupée, on swappe
rien d'anormal ou alors, les données fournies sont incomplétes
Tu dois confondre avec le projet Nebula de la NASA (qui date de 2008), OpenNebula est un projet issu de la recherche européenne (qui a démarré en 2005, OpenStack lui en 2010).
on ne peut s'empêcher en te lisant de lire aussi "fedora" entre les lignes
Oui, je me base sur mon expérience de développeur fedora (et de contributeur occasionnel à d'autres distros) pour réfléchir à la suggestion de SJR.
Et tout le monde ne pas suivre le rythme Fedora
Le cycle de 6 mois n'est pas le graal non plus, il a fait ses preuves comme le système de rolling release ou le cycle de plus ou moins 2 ans de Debian. Par contre, le cycle de 1 mois est clairement bâtard entre une rolling release sans l'exigence de la qualité (dans ArchLinux ou Gentoo, ce n'est pas la foire, les nouveautés passent en stable quand c'est prêt, pas le stress de la deadline qui arrive ou d'attendre la prochaine), et un cycle de 6 mois qui permet d'avoir des cycles itératifs tout en gardant une ligne conductrice à moyen et long terme.
C'est même le problème, quelle vision à long terme avec une cadence infernale de 1 mois (oui, c'est intenable à l'échelle d'une distro). La seule façon de tenir, ce serait de réduire le nombre de paquets maintenus mais je vois mal ubuntu le faire, sans compter qu'à ce rythme, bon nombre de contributeurs décrocheront et tu retrouveras avec l'effet inverse, un système de base éventuellement plus robuste (mais moins innovant) et des paquets contrib complétement pétés parce que les mainteneurs n'auront plus le temps de suivre.
avoir un système stable et des logiciels tiers très à jour.
Le plus simple, c'est reprendre la recette BSD: un système de base réduit mais cohérent et un système de ports qui évoluent indépendamment. Tu as un système stable car maintenu par une équipe certes réduite mais qui maitrise l'ensemble du code, et des logiciels tiers à jour, car ils évoluent sans dépendre de la base ou des autres ports.
Tu es un peu entrain de critiquer la méthode Agile
Loin de là, primo, entre un projet logiciel et une distro l'échelle n'est pas la même (sans compter le déphasage inéluctable avec les projets upstream), secundo tu confonds itération et cycle complet (à l'origine le cycle de 6 mois introduit par GNOME repris par Fedora puis Ubuntu est par essence agile), tertio avoir des releases tout les mois, certes tu auras un diff plus petit mais parce que derrière, les développeurs passeront moins de temps à développer (lors d'une itération, certains délais sont incompressibles comme la QA), une itération d'un mois c'est trop court pour développer des fonctionnalités majeures/tester/valider et qu'en plus tu auras moins de testeurs alors qu'en pratique on en manque cruellement.
Projets agiles != projets bouclés en quelques semaines
Pour lui une période de 1 mois permet d'avancer par petites touches mieux gérées et étalées qu'un gros bloc sur 6 mois qui touche des trucs trop sensibles pour faire le boulot dans les temps et/ou proprement.
Dans les faits, les testeurs sont peu nombreux, les testeurs qui font des retours le sont encore moins, des testeurs productifs ça se compte sur les doigts. Si tu développes les fonctionnalités dans un PPA à part, la plupart des mecs n'activeront pas parce que ça ne les intéressera pas, parce qu'ils n'y penseront pas etc ...donc mécaniquement moins de testeurs (alors qu'il en faudrait plus !)
Sans compter que certains composants ont un cycle de développement plus long qu'un mois donc le temps d'arriver à un truc stable, bah tu retrouveras avec un cycle de test d'environ 1 mois ou 2 mois au lieu de 4 à 6 mois (donc les développeurs upstream auront beaucoup moins de retours et potentiellement moins de temps pour corriger les bogues).
La proposition de SJR ne fonctionne que si on a un fonctionnement type cathédrale "je maitrise tout le code", ça marche pour chromium, ça ne marchera pas avec une distro GNU/Linux qui fonctionne selon un mode bazar.
C'est fait dans un ppa à part, non soumis au cycle de 1 mois et accessible par les volontaires.
Dans un coin, donc jamais testé. Déjà que pour les versions de développement (alpha, béta etc ...) c'est la misère pour trouver des testeurs, si tu dois foutre chaque nouvelle fonctionnalité dans un truc à part, t'auras forcément moins de monde pour tester, c'est mécanique.
Ben justement, il ne veut pas que ce soit l'utilisateur lambda qui découvre les problèmes, parce que ca entraine une dégradation de l'image de qualité de la distri.
L'utilisateur lambda n'installe pas les versions de développement, si tu lui fais faire des mises à jours tout les mois:
soit t'es ultra conservateur: ubuntu perds tout intérêt par rapport à une debian unstable
soit tu ne l'es pas: l'utilisateur va s'en manger plein la gueule, c'est mécanique.
Je ne pense pas qu'Ubuntu risque grand chose si la chose est gérée intelligemment.
Ils ont déjà du mal à tenir le rythme de 6 mois, alors 1 mois ... 3 mois aurait été envisageable si on limite le nombre de paquets supportés mais 1 mois c'est un rythme bâtard et intenable par la communauté. Passer à un système de rolling release aurait été plus sensé (d'autant qu'avec les PPA, c'est faisable techniquement)
Pour résumer:
* ce n'est pas une rolling release
* c'est un cycle de développement de 1 mois, on compresse encore plus les phases de développement.
* une cadence infernale: on n'a plus le temps ni même le recul pour développer/corriger les fonctionnalités.
* moins de testeurs: les développeurs bossent dans leur coin et leur travail n'est reversé dans le master que lorsque c'est prêt (l'assurance de n'avoir aucun retour des utilisateurs)
* échec garanti: Canonical a déjà du mal à tenir une cadence de 6 mois/18 mois pour les LTS, alors des cycles de 1 mois, c'est peine perdue.
En bref, je me demande qu'est-ce qu'on lui donne à fumer au père Scott chez Google ? Ce qui marche pour chromium (avec le résultat qu'on connait: bibliothèques forkés sauvagement inclus dans le tronc, réinvention du système de construction, gestion désastreuse et brutale de la communauté, bref un joli tas de merde bien emballé) ne marchera pas dans une distro (pas le même scope, pas le même niveau d'exigence qualité y compris chez Ubuntu -enfin j'espère qu'ils n'oseront pas descendre aussi bas dans la merditude et qu'ils continueront à essayer de se rapprocher du niveau de qualité de la distro maman aka Debian)
À priori, c'est pour se caler avec l'Open World Forum qui débutera le lendemain (la plupart des intervenants seront également présents là-bas).
Ça va troller sec sur les diverses initiatives de standardisation du cloud notamment l'IaaS (deltacloud vs openstack vs opennebula vs OCCI) pendant cette semaine.
Le problème c'est que les designers vont plus vite que les développeurs, l'ergonomie du shell a été conçu par des designers qui avaient en tête des interfaces tactiles sans tenir compte de l'état d'avancement des solutions techniques (d'après mccann, c'est pour ne pas mettre des bâtons dans les roues des développeurs).
Le fait de grouper les fenêtres par applications n'est pas une mauvaise idée, mais je trouve que l'on perd en lisibilité et qu'il est dans certains cas plus dur de basculer d'une fenêtre à une autre
L'extension alternate-tab permet justement de rétablir le alt-tab classique par fenêtre
mais je n'ai pas encore trouver comment y changer de fenêtres ou de bureau sans toucher à la souris.
L'extension windowNavigator te permet de naviguer dans le mode overlay avec le clavier (par exemple, en appuyant sur alt, les fenêtres sont numérotés et tu tapes le numéro de celle qui t'intéresse)
ce qui m'intéresse c'est du post-commit review (pour ne pas perturber les us et coutumes dans un premier temps).
C'est une fausse bonne idée, certes le pre-commit review bouscule les habitudes, mais ça aide à acquérir les bonnes habitudes (respect des coding standards, découper ses patchs, faire attention aux changement d'API/ABI, tests de non-régression etc...) parce que les développeurs au bout d'un moment auront marre de voir leurs patchs mal branlés refusés.
Le problème du post-commit reviewing, c'est que le reviewer va systématiquement passer son temps à corriger le code pourrave et les développeurs ne prendront jamais le temps de soigner leurs commits. VOire si le ratio reviewees/reviewers ou le volume de code est trop élévé, le système finit par imploser. En général, la revue de code à posteriori ne fonctionne que si tu as gelé la base de code (avant une release, ou pendant un audit).
Et non, Unity utilise la plateforme de dev offerte pas GNOME, que tu le veuilles ou pas, ainsi que les applications de cette environnement.
Que tu le veuilles ou non, Unity construit sa propre plateforme qui s'appuie partiellement sur la partie GNOME et en réécrit une partie (lightdm, appindicators, bamf, lenses, etc ...). Au fur et à mesure que se construiront les deux bureaux, une application Unity (c'est à dire reposant sur libunity) ne sera pas une application GNOME3 (c'est à dire intégré au shell) et vice-versa, du moins sans adaptation.
C'est fallacieux de dire que Unity, GNOME Shell c'est juste un changement de peinture, l'architecture de l'UX divergent sérieusement entre les deux bureaux.
Euh, tu le fais exprès ? Plus ca va plus c'est débile ce que tu écris...
Quand on n'a pas d'arguments, on tombe dans les attaques personnelles
pneu == voiture
GNOME Shell is the defining technology of the GNOME 3 user experience.http://live.gnome.org/GnomeShell
GNOME Shell est au coeur de l'expérience utilisateur de GNOME3, sans GNOME Shell (ou classic), ça n'est plus GNOME, point barre. Même le plus malcomprenant des ânes bâtés est capable de comprendre ça.
Si ça ne te suffit pas, visite le site promotionnel de GNOME3, on ne mentionne nulle part l'existence d'Unity ou de shells alternatifs. http://gnome3.org/
En résumé:
* Unity est un projet indépendant de GNOME.
* Unity n'est pas GNOME.
* Unity réutilise une partie de la plateforme GNOME pour construire sa plateforme.
Tu auras beau faire appel au champs de distortion de la réalité, tu ne peux pas changer les faits.
seul manque les trucs en rapport avec Gnome shell...
GNOME Shell == GNOME3, il n'y a pas GNOME Shell ou GNOME Classic, ça n'est pas GNOME.
j'attend de voir un développeur de toute les boites que tu cites avoir les couilles de coder un truc (un gros truc), de valider que ca fonctionne et de le proposer pour voir comment il va se faire recevoir.
Mutter par Intel au coeur de GNOME3, Lanedo qui maintient Gtk+, Collabora qui maintient Empathy, etc ... Les gros développements dans GNOME, ça se fait au sein de GNOME. Même Red Hat n'arrive pas avec son broll et l'impose au sein de GNOME comme ça.
Là, tu me donnes un liste de boites ayant des devs au sein du projet GNOME, ce n'est pas ce que fait Canonical qui eux expérimentent.
Parce que les gens de SuSE n'expérimentent pas ? expérimenter, ça veut dire, je développe tout dans mon coin et j'impose aux autres ? drôle de façon de voir la collaboration !
[^] # Re: Killer features !
Posté par GeneralZod . En réponse au journal Gnome 3.2 est sorti!. Évalué à 8.
remote desktop (temps de réflexion: 0.00000000042s)
[^] # Re: Barre des tâches
Posté par GeneralZod . En réponse au journal Gnome 3.2 est sorti!. Évalué à 2.
Il n'y a pas besoin de barre de tâches, le but de GNOME Shell n'est pas de redévelopper GNOME autour de paradigmes vieux de 30 ans, mais de réinventer la façon dont on interagit avec sa machine. Si tu t'attends à retrouver ta barre de tâches, tu peux changer de bureau, il y a peu de chance que ça arrive.
[^] # Re: SQLite
Posté par GeneralZod . En réponse au journal Mysql, je t'aime un peu, à la folie, mais pas trop libre. Évalué à 8.
C'est pas les mêmes cas d'utilisation, SQLite est une base de donnée embarquée alors que MySQL est un serveur de base de données.
SQLite est certes très simple à utiliser, et est extrêmement avantageux dans bon nombre de cas (base embarquée, prototypage etc ...), mais ne gère absolument la concurrence, ne passe pas à l'échelle (à partir d'un giga de données, il est futile de continuer à utiliser SQLite), ne gère pas les utilisateurs.
[^] # Re: Take your responsabilities, shut up and code !
Posté par GeneralZod . En réponse au journal Mysql, je t'aime un peu, à la folie, mais pas trop libre. Évalué à 5.
drizzle ne réponds pas aux même cahier des charges, il est optimisé pour la mise à l'échelle et les performances (d'où l'abandon de la couche moteurs de stockage), il supporte moins de types, pas de support du FTS (enfin, le support n'était pas non plus extra dans MySQL ou MariaDB), il utilise un nouveau protocole basé sur Google Protocol Buffers et n'est donc pas compatible avec les clients existants etc ...
MariaDB est un remplacement "drop-in" à MySQL (ce qui n'est pas sans poser de problèmes pour les distributions, du fait que les fichiers sont nommés de façon identiques), ça juste marche.
# Take your responsabilities, shut up and code !
Posté par GeneralZod . En réponse au journal Mysql, je t'aime un peu, à la folie, mais pas trop libre. Évalué à 10.
Ce problème a été mentionné par Colin Charles (employé de Monty Programs et auparavant par MySQL AB) lors de l'Open World Forum le week-end dernier et c'est effectivement un vrai problème.
Monty est en partie responsable de cette situation (il a choisi le modèle double-licence, il a vendu en toute connaissance de cause MySQL à Sun sans aucune garantie), donc au lieu de passer son temps à se plaindre, il ferait mieux d'agir. Il serait grand temps que MariaDB devienne un vrai fork de MySQL et arrête de jouer au jeu du chat et de la souris avec Oracle. Soit Oracle est un partenaire correct et on travaille avec lui, soit il ne l'est pas et on se casse définitivement (merci la GPL).
C'est une nouvelle neuve que de savoir qu'Oracle c'est gros vilains méchants pas beaux et qui sentent mauvais. Monty c'est guère mieux, c'est grippe-sou qui se plaint qu'on ne lui rende pas la pleine propriété de son bien sans contrepartie après l'avoir vendu au prix fort.
[^] # Re: Pas de balooning
Posté par GeneralZod . En réponse au message Pourquoi ce #%$$ de système s'obstine à swapper ?. Évalué à 2.
je résume:
* environ 20 Go de RAM
* jusqu'à au moins 250 Mo de RAM libre ==> soit moins de 2% de RAM libre
* swappiness à 15% c'est à dire si 85% de la RAM occupée, on swappe
rien d'anormal ou alors, les données fournies sont incomplétes
[^] # Re: 3 coeurs ?
Posté par GeneralZod . En réponse au sondage Quel est le type de processeur de votre ordinateur personnel ?. Évalué à 4.
AMD Phenom X3
http://www.ldlc.com/informatique/piece/processeur/c4300/+fv579-6009.html
[^] # Re: Coïncidence ?
Posté par GeneralZod . En réponse à la dépêche OpenStack in Action! — Paris, le 21 septembre 2011. Évalué à 2.
Tu dois confondre avec le projet Nebula de la NASA (qui date de 2008), OpenNebula est un projet issu de la recherche européenne (qui a démarré en 2005, OpenStack lui en 2010).
# 16 cores pĥysiques ...
Posté par GeneralZod . En réponse au sondage Quel est le type de processeur de votre ordinateur personnel ?. Évalué à 3.
... parce que je le vaux bien !
[^] # Re: Les monstres.
Posté par GeneralZod . En réponse au journal Comment se débarrasser des machines en fin de vie ?. Évalué à 2.
ça peut être sympa à des fins éducatives (université, lycée, hackerspace, etc ...)
[^] # Re: liberté, mais pas de p0rn
Posté par GeneralZod . En réponse au journal Ceci est un JBT*. Évalué à 5.
tu as encore des choses à apprendre, petit !
[^] # Re: de la folie pure
Posté par GeneralZod . En réponse au journal Ubuntu : une nouvelle version tous les mois ?. Évalué à 5.
Oui, je me base sur mon expérience de développeur fedora (et de contributeur occasionnel à d'autres distros) pour réfléchir à la suggestion de SJR.
Le cycle de 6 mois n'est pas le graal non plus, il a fait ses preuves comme le système de rolling release ou le cycle de plus ou moins 2 ans de Debian. Par contre, le cycle de 1 mois est clairement bâtard entre une rolling release sans l'exigence de la qualité (dans ArchLinux ou Gentoo, ce n'est pas la foire, les nouveautés passent en stable quand c'est prêt, pas le stress de la deadline qui arrive ou d'attendre la prochaine), et un cycle de 6 mois qui permet d'avoir des cycles itératifs tout en gardant une ligne conductrice à moyen et long terme.
C'est même le problème, quelle vision à long terme avec une cadence infernale de 1 mois (oui, c'est intenable à l'échelle d'une distro). La seule façon de tenir, ce serait de réduire le nombre de paquets maintenus mais je vois mal ubuntu le faire, sans compter qu'à ce rythme, bon nombre de contributeurs décrocheront et tu retrouveras avec l'effet inverse, un système de base éventuellement plus robuste (mais moins innovant) et des paquets contrib complétement pétés parce que les mainteneurs n'auront plus le temps de suivre.
Le plus simple, c'est reprendre la recette BSD: un système de base réduit mais cohérent et un système de ports qui évoluent indépendamment. Tu as un système stable car maintenu par une équipe certes réduite mais qui maitrise l'ensemble du code, et des logiciels tiers à jour, car ils évoluent sans dépendre de la base ou des autres ports.
[^] # Re: de la folie pure
Posté par GeneralZod . En réponse au journal Ubuntu : une nouvelle version tous les mois ?. Évalué à 3.
Loin de là, primo, entre un projet logiciel et une distro l'échelle n'est pas la même (sans compter le déphasage inéluctable avec les projets upstream), secundo tu confonds itération et cycle complet (à l'origine le cycle de 6 mois introduit par GNOME repris par Fedora puis Ubuntu est par essence agile), tertio avoir des releases tout les mois, certes tu auras un diff plus petit mais parce que derrière, les développeurs passeront moins de temps à développer (lors d'une itération, certains délais sont incompressibles comme la QA), une itération d'un mois c'est trop court pour développer des fonctionnalités majeures/tester/valider et qu'en plus tu auras moins de testeurs alors qu'en pratique on en manque cruellement.
Projets agiles != projets bouclés en quelques semaines
[^] # Re: de la folie pure
Posté par GeneralZod . En réponse au journal Ubuntu : une nouvelle version tous les mois ?. Évalué à 5.
Dans les faits, les testeurs sont peu nombreux, les testeurs qui font des retours le sont encore moins, des testeurs productifs ça se compte sur les doigts. Si tu développes les fonctionnalités dans un PPA à part, la plupart des mecs n'activeront pas parce que ça ne les intéressera pas, parce qu'ils n'y penseront pas etc ...donc mécaniquement moins de testeurs (alors qu'il en faudrait plus !)
Sans compter que certains composants ont un cycle de développement plus long qu'un mois donc le temps d'arriver à un truc stable, bah tu retrouveras avec un cycle de test d'environ 1 mois ou 2 mois au lieu de 4 à 6 mois (donc les développeurs upstream auront beaucoup moins de retours et potentiellement moins de temps pour corriger les bogues).
La proposition de SJR ne fonctionne que si on a un fonctionnement type cathédrale "je maitrise tout le code", ça marche pour chromium, ça ne marchera pas avec une distro GNU/Linux qui fonctionne selon un mode bazar.
[^] # Re: de la folie pure
Posté par GeneralZod . En réponse au journal Ubuntu : une nouvelle version tous les mois ?. Évalué à 3.
Dans un coin, donc jamais testé. Déjà que pour les versions de développement (alpha, béta etc ...) c'est la misère pour trouver des testeurs, si tu dois foutre chaque nouvelle fonctionnalité dans un truc à part, t'auras forcément moins de monde pour tester, c'est mécanique.
L'utilisateur lambda n'installe pas les versions de développement, si tu lui fais faire des mises à jours tout les mois:
soit t'es ultra conservateur: ubuntu perds tout intérêt par rapport à une debian unstable
soit tu ne l'es pas: l'utilisateur va s'en manger plein la gueule, c'est mécanique.
Ils ont déjà du mal à tenir le rythme de 6 mois, alors 1 mois ... 3 mois aurait été envisageable si on limite le nombre de paquets supportés mais 1 mois c'est un rythme bâtard et intenable par la communauté. Passer à un système de rolling release aurait été plus sensé (d'autant qu'avec les PPA, c'est faisable techniquement)
# de la folie pure
Posté par GeneralZod . En réponse au journal Ubuntu : une nouvelle version tous les mois ?. Évalué à 5.
Pour résumer:
* ce n'est pas une rolling release
* c'est un cycle de développement de 1 mois, on compresse encore plus les phases de développement.
* une cadence infernale: on n'a plus le temps ni même le recul pour développer/corriger les fonctionnalités.
* moins de testeurs: les développeurs bossent dans leur coin et leur travail n'est reversé dans le master que lorsque c'est prêt (l'assurance de n'avoir aucun retour des utilisateurs)
* échec garanti: Canonical a déjà du mal à tenir une cadence de 6 mois/18 mois pour les LTS, alors des cycles de 1 mois, c'est peine perdue.
En bref, je me demande qu'est-ce qu'on lui donne à fumer au père Scott chez Google ? Ce qui marche pour chromium (avec le résultat qu'on connait: bibliothèques forkés sauvagement inclus dans le tronc, réinvention du système de construction, gestion désastreuse et brutale de la communauté, bref un joli tas de merde bien emballé) ne marchera pas dans une distro (pas le même scope, pas le même niveau d'exigence qualité y compris chez Ubuntu -enfin j'espère qu'ils n'oseront pas descendre aussi bas dans la merditude et qu'ils continueront à essayer de se rapprocher du niveau de qualité de la distro maman aka Debian)
[^] # Re: Coïncidence ?
Posté par GeneralZod . En réponse à la dépêche OpenStack in Action! — Paris, le 21 septembre 2011. Évalué à 2.
À priori, c'est pour se caler avec l'Open World Forum qui débutera le lendemain (la plupart des intervenants seront également présents là-bas).
Ça va troller sec sur les diverses initiatives de standardisation du cloud notamment l'IaaS (deltacloud vs openstack vs opennebula vs OCCI) pendant cette semaine.
[^] # Re: En ce qui me concerne...
Posté par GeneralZod . En réponse au journal Unity, Gnome 3 ... mon expérience.. Évalué à 2.
Le problème c'est que les designers vont plus vite que les développeurs, l'ergonomie du shell a été conçu par des designers qui avaient en tête des interfaces tactiles sans tenir compte de l'état d'avancement des solutions techniques (d'après mccann, c'est pour ne pas mettre des bâtons dans les roues des développeurs).
[^] # Re: En ce qui me concerne...
Posté par GeneralZod . En réponse au journal Unity, Gnome 3 ... mon expérience.. Évalué à 2.
L'extension alternate-tab permet justement de rétablir le alt-tab classique par fenêtre
L'extension windowNavigator te permet de naviguer dans le mode overlay avec le clavier (par exemple, en appuyant sur alt, les fenêtres sont numérotés et tu tapes le numéro de celle qui t'intéresse)
[^] # Re: Définition de stable...
Posté par GeneralZod . En réponse au journal Unity, Gnome 3 ... mon expérience.. Évalué à 6.
Pourquoi ? Fedora est effectivement beaucoup plus stable qu'Ubuntu ..
[^] # Re: Template programming
Posté par GeneralZod . En réponse au message Faire une réduction de code en supprimant les fonctions non utilisées. Évalué à 2.
C'est déjà le cas avec les templates, tu n'utilises pas, ça n'est pas compilé, ça n'existe pas dans le binaire.
[^] # Re: A tester ...
Posté par GeneralZod . En réponse à la dépêche Review Board 1.6. Évalué à 6.
C'est une fausse bonne idée, certes le pre-commit review bouscule les habitudes, mais ça aide à acquérir les bonnes habitudes (respect des coding standards, découper ses patchs, faire attention aux changement d'API/ABI, tests de non-régression etc...) parce que les développeurs au bout d'un moment auront marre de voir leurs patchs mal branlés refusés.
Le problème du post-commit reviewing, c'est que le reviewer va systématiquement passer son temps à corriger le code pourrave et les développeurs ne prendront jamais le temps de soigner leurs commits. VOire si le ratio reviewees/reviewers ou le volume de code est trop élévé, le système finit par imploser. En général, la revue de code à posteriori ne fonctionne que si tu as gelé la base de code (avant une release, ou pendant un audit).
[^] # Re: Unity ?
Posté par GeneralZod . En réponse au sondage A propos de gnome 3. Évalué à 3.
Que tu le veuilles ou non, Unity construit sa propre plateforme qui s'appuie partiellement sur la partie GNOME et en réécrit une partie (lightdm, appindicators, bamf, lenses, etc ...). Au fur et à mesure que se construiront les deux bureaux, une application Unity (c'est à dire reposant sur libunity) ne sera pas une application GNOME3 (c'est à dire intégré au shell) et vice-versa, du moins sans adaptation.
C'est fallacieux de dire que Unity, GNOME Shell c'est juste un changement de peinture, l'architecture de l'UX divergent sérieusement entre les deux bureaux.
Cf document architecture Unity https://wiki.ubuntu.com/Unity?action=AttachFile&do=view&target=Unity_Architecture.pdf
Je te cite textuellement:
Mauvaise foi, toussa ... Tu réagissais au fait que je disais que Unity n'était pas GNOME3.
[^] # Re: Unity ?
Posté par GeneralZod . En réponse au sondage A propos de gnome 3. Évalué à 2.
Quand on n'a pas d'arguments, on tombe dans les attaques personnelles
GNOME Shell is the defining technology of the GNOME 3 user experience. http://live.gnome.org/GnomeShell
GNOME Shell est au coeur de l'expérience utilisateur de GNOME3, sans GNOME Shell (ou classic), ça n'est plus GNOME, point barre. Même le plus malcomprenant des ânes bâtés est capable de comprendre ça.
Si ça ne te suffit pas, visite le site promotionnel de GNOME3, on ne mentionne nulle part l'existence d'Unity ou de shells alternatifs.
http://gnome3.org/
En résumé:
* Unity est un projet indépendant de GNOME.
* Unity n'est pas GNOME.
* Unity réutilise une partie de la plateforme GNOME pour construire sa plateforme.
Tu auras beau faire appel au champs de distortion de la réalité, tu ne peux pas changer les faits.
[^] # Re: Unity ?
Posté par GeneralZod . En réponse au sondage A propos de gnome 3. Évalué à 2.
GNOME Shell == GNOME3, il n'y a pas GNOME Shell ou GNOME Classic, ça n'est pas GNOME.
Mutter par Intel au coeur de GNOME3, Lanedo qui maintient Gtk+, Collabora qui maintient Empathy, etc ... Les gros développements dans GNOME, ça se fait au sein de GNOME. Même Red Hat n'arrive pas avec son broll et l'impose au sein de GNOME comme ça.
Parce que les gens de SuSE n'expérimentent pas ? expérimenter, ça veut dire, je développe tout dans mon coin et j'impose aux autres ? drôle de façon de voir la collaboration !