Effectivement si E est une autre version de B, il faudrait présenter à l'utilisateur la possibilité de désintaller B et d'installer E à la place.
Sinon, si E n'est pas une autre version de B, je ne vois pas pourquoi on devrait parcourir la base pour trouver une solution à l'action de l'utilisateur... dans ce cas on ne devrait que lui présenter l'information du conflit et pas d'autre solution que de désinstaller B.
VirtualBox : pratique pour virtualiser un desktop PC, il a l'avantage d'être facile à paramétrer et à utiliser pour l'utilisateur final. Les dernières versions font état du support d'openGL directement sur la machine embarqué.
pour répondre a ta dernière question, le calcul sur GPU se prette très bien aux calculs matriciels, vectoriels....
il y a une pelleté d'application a ces domaines :
- traitement de l'image
- simulation de problèmes physiques (météo, big bang, aéronotique ...)
- mathématiques vectorielles/matricielles
- analyse spectrale
Non, ça n'as rien a voir... QtDesigner tout comme Glade, c'est plutôt ce qu'on appelle du RAD (Rapid Application Developpement) avec un système de déclaration des widgets.
Il y a un langage déclaratif pour Qt si je ne m'abuse... mais je crois qu'il ne sortira officiellement des BACS que pour la 4.6
Sinon, Il y a Glade pour Gtk/Gtkmm et le nouveau loadeur GtkBuilder... mais il s'agit plus de RAD que de langage déclaratif ici.
MetaOcaml n'est plus maintenu depuis 2006 ... ça donne pas vraiment envie de l'utiliser.
Mais je n'ai rien contre Ocaml, ce n'est juste pas un remplaçant à c++ à mes yeux.
Quand à ta comparaison Ocaml vs C , on peut dire la même chose C++ vs C
Et je trouve qu"écrire des interface graphiques, des serveurs asynchrones, faire de la programmation parallèle etc, ce n'est pas le fort d'ocaml si on le compare à C++
Ce n'est donc pas une attaque, mais pour le code de mes productions, je ne mettrais jamais de Ocaml. Mais ce n'est que mon point de vue, et peut être ai-je tord.
Avec ocaml tu peux certainement faire des conteneurs génériques, mais certainement pas du meta programming et encore moins de template meta programming et donc pas de concepts non plus... c'est indéniablement moins puissant que c++ ou D de ce point de vue...
Ocaml répond à certains besoins, mais j'avoue que pondre une interface graphique avec du langage fonctionnel, même s'il supporte des paradigmes impératif est une vrai plaie...
Par contre pour pondre des algorithmes, un compilateur etc... j'avoue qu'ocaml est au dessus du lot!
Franchement, c'est un coup dur!
Je programme en C++ sur 90% de mon code... et 10% de C.
Les templates, et particulièrement celles de la Stl, Boost ou gtkmm et consorts génèrent des erreurs difficiles à diagnostiquer.
Avec mon expérience, maintenant je décrypte ces erreurs très vite, mais il m'a fallu accumuler une grosse expérience pour acquérir des automatismes à ce niveau là.
Du coup, quand il s'agit d'embaucher un développeur c++, prendre des débutants est un choix risqué, car je sais que je vais devoir passer énormément de temps à l'encadrer et lui expliquer comment trouver les sources d'erreurs... la productivité s'en retrouve bien vite plombée.
J'attendais donc les concepts avec une grande impatience. même si je suis ravi qu'il y ait l'inclusion du mot clef "auto" et les fonctions "lambda", c'est une fonctionnalité indéniablement utile pour le débutant qui vient de sauter.
ça me laisse un peu perplexe, et encore plus le fait que le standard se voit repoussé.
Le comité de standardisation semble empêtré dans des débats interminable. Ils avancent à une vitesse d'escargot! Les techno c++ commencent à accumuler un retard considérable.
Attendre encore 5 à 7 ans pour voir l'inclusion des concepts dans le c++ me semble être un avis de décès pour ce langage.
J'attends encore un remplaçant convainquant, car D ne m'a pas encore séduit... même s'il a beaucoup d'atouts, il lui manque aussi les concepts et il y a encore trop peu de bibliothèques disponible à mon goût.
Pour faire du code dépendant de la plateforme GLib, j'envisage d'approfondir mon étude de Vala, même s'il n'y a pas de templates mais plutôt des Generics comme en Java. Cependant ce langage est encore trop jeune pour passer en production de mon point de vue.
euh, ça fait longtemps qu'on est dans la phase 3 avec l'opération "get the facts"...
Je crois qu'on est plutôt dans la transition III vers IV qui va durer très longtemps à mon avis...
Je ne lui jetterais pas la pierre, il a vraiment investis beaucoup de temps dans ce projet..
C'était mon professeur quand j'étais en école d'ingénieur, et c'est un type que j'ai toujours apprécié, super balèze, il nous a initié à smarteiffel (smalleiffel à l'époque), m'as appris beaucoup de choses et était vraiment à l'écoute de ses élèves.
Pour l'ambiance qui règne dans l'équipe, je dirais qu'elle doit être bonne, en tout cas à l'époque l'ambiance était au beau fixe car son projet était vraiment innovant.
Franchement, le connaissant, je pense qu'il a essayé d'améliorer Eiffel, de toute bonne foi.
Je pense qu'effectivement la rétro-compatibilité n'était pas son but premier, mais améliorer le language, expérimenter de nouvelles méthode d'optimisations etc...
Ne l'oublions pas, Dominique Colnet est un chercheur, il aime les défis, et répondre aux critiques ne doit pas être son passe temps favoris...
Je ne pense pas que le problème soit, seule Solaris rapporte!
La version opensolaris permet à sun (et donc maintenant oracle) d'avoir des beta testeurs, une communauté qui peut découvrir des problèmes et proposer des solutions etc.
OpenSolaris permet donc à Solaris d'être plus stable, ça rapporte indirectement, sans compter que ça permet le marketing viral. Un utilisateur content de son OpenSolaris pourra faire du lobbying dans sa société pour que sa direction installe du Solaris...
Je pense donc que ce serait un mauvais pari pour oracle de fermer Opensolaris.
GTK+ a enfin cette fonctionnalité avec seulement quelques années de retard sur Qt.
Ouais, enfin Qt 4.4 est sortis l'année dernière en Mai... un an et demi de retard c'est pas quelques années! Le troll est un peu poilu, non?
De plus à la sortie en septembre, tous les backend seront supportés aussi, il n'y a qu'à voir les patch d'aujourd'hui et d'il y a 4 jours... il s'agit du portage des backends win32 et directFB... il me semble que mac avance sur un projet séparé et que les merges se font moins souvent.
En fait il faut ouvrir un compte sur le bugzilla pour pouvoir avoir les adresses de contacts... sinon, le robots snifeurs auraient tôt fait de spammer sa boite mail... même si je suis certain que c'est déjà le cas.
Donc, déjà ouvre un compte, tu verra son adresse e-mail (en tout cas, moi je la vois).
Ensuite, s'il te plait, évite de lui écrire si tu n'as pas de code à fournir ou une mise a jour du patch déjà proposé envers la branche courante de developpement (git clone est t'on amis). Je t'assure qu'ils sont débordés, si tu veux faire avancer ce bug, il faut arriver avec quelque chose pour lui décharger au maximum le travail.
Si tu n'arrive pas à joindre Christian (ce qui expliquerais pourquoi le bug stagne), essaye de contacter matthias classen, mais encore une fois, il te faut proposer quelque chose, un patch tout fait et testé... il pourra peut être faire débloquer la situation (attention, matthias est encore plus débordé que d'autres, donc y aller mollo)
Je n'ai pas de liens vers les patchs en question, ce n'est pas moi qui travaille dessus, désolé.
Cependant, j'en vois qui datent de début mai... donc oui certains sont peu être traités rapidement, mais pas tous...
Je dirais que l'équipe est en effet en sous effectifs. Il y a peu de bon programmeur en C capable d'investir du temps dans la programmation type GObject, et encore moins avec assez de temps pour devenir mainteneur...
Personnellement, je n'ai pas le temps de devenir mainteneur, je préfère soumettre des patchs. Envoyer 4 ou 5 mails pour un patch ce n'est pas la mort comparé à en recevoir des centaines tout en faisant avancer le code qu'on doit pondre sur d'autres projets.
D'autant plus qu'en attendant, je garde une version de gtk avec mes patchs, j'en ai encore quelques un qui ne sont pas appliqués, ça ne me dérange pas outre mesure, vu que je suis en mesure d'utiliser ma propre version.
Je soumet mes patchs pour en faire profiter le plus grand nombre, mais je garde à l'esprit qu'ils ne sont pas forcément du gout de tout le monde, mais parfois j'obtiens le soutiens de quelqu'un qui en a besoin, et ça permet à des patch de rentrer dans la version officielle.
Je pense que ce n'est d'ailleurs pas qu'un problème de Gtk, sur le kernel, réussir à soumettre un patch me semble bien plus difficile, bien que je n'ai jamais essayé.
Sur Qt on peut en soumettre depuis peu et un collègue qui bosse avec moi à déjà soumis des patchs, mais on lui a dis qu'ils ne pourront pas être intégrés avant quelques mois faute de temps...
Bref ça depend de la priorité que les mainteneurs affectent au patch, à la taille de l'équipe de mainteneurs, à la qualité du code fournis, à la volonté de celui qui soumet le patch de le voir intégrer.
c'est ça le travail communautaire.
c'est pas vraiment ici que t'arrivera à faire avançer le shmilblick sur ce bug...
Mon expérience est qu'à chaque fois que j'ai voulu faire appliquer un de mes patch, comme je ne suis pas mainteneur officiel de gtk, j'ai fait un peu de lobbying auprès du mainteneur concerné par mail pour qu'il l'applique. Ils ont beaucoup de boulot et donc souvent ils te disent ok si tu trouve quelqu'un pour faire un review de ton patch. ce que j'ai fait en postant sur la mailing list ou en demandant directement à mattias s'il pouvait y jeter un oeil.
une fois que t'as un feu vert, tu fait le forcing auprès d'un mainteneur pour qu'il applique le patch vu que t'as obtenu le feu vert (que tu met en copie)...
Je ne connais pas wayland, mais tu peux d'ors et déjà utiliser cette version de developpement et faire remonter les bugs que tu trouvera à l'équipe de Gtk+ (sur le bug traker de preference).
En effet, gtk+ 2.17.4 (dernière version taggé) peut être installé en parrallèle avec la version stable, à condition de l'installer dans /usr/local/ et non /usr.
pour celà un petit ./configure --prefix=/usr/local puis make puis make install suffira
Vu que tu fais un journal là dessus, est-ce que tu as un lien vers les spécifications du protocol SPICE?
Ou bien ce n'est pas encore publié?
Y a t'il eut une communication de Redhat sur les brevets qu'ils detiennent sur SPICE après le rachat de Qumranet?
Tu veut comparer les fonctionnalités entre Debian stable et Ubuntu? (ne me parle pas d'unstable alias SID, il y a autant de bug si ce n'est plus que sur Ubuntu)...
Non, mais faut arrêter le FUD, il a dit tout comme moi que sous Fedora l'hibernation était fonctionnelle...
Il n'a pas dit qu'il n'y avait pas des bogues avec certains drivers...
D'ailleurs on remarquera que souvent les problèmes sont dus à des drivers proprios (pas toujours en plus) qui font mal leur boulot...
Mais de là dire qu'il ment en prétendant qu'il y a une hibernation fonctionnelle sous Fedora, ce n'est pas un mensonge, tout au plus un manque d'exhaustivité car il n'a pas listé les drivers qui pourraient poser problème.
Mais sa réponse aurait été un peu trop longue.
Le posteur demande des idées de distribution.
Les gens lui proposent, il en fait ce qu'il veut, voir il peu se renseigner un peu plus avant de sauter le pas...
c'est sur qu'il n'y a jamais eu de problème de stabilité sous les autres distributions qui sortent...
mais alors vraiment jamais... c'est pour ça qu'il n'y a jamais le moindre retour de bogue des autres distribution...
Je rigole devant la naïveté des FUDs qui sont lançés à l'encontre d'Ubuntu...
Et bien je dois avoir une chance incroyable, car sur la mienne je n'ai jamais eu de souci d'hibernation.
Maintenant dis moi le nom de ta distribution et on verra si personne ne se plaint de problèmes d'hibernation, juste pour rire un peu...
- Installation graphique avec un live CD super rapide
- Un chargement rapide grâce à UpStart
- Une installation simplifié des drivers proprios
- Une installation guidée des codecs à la demande
- Un nombre de paquets aussi grand que Debian
- le système de paquet de debian et apt-get, aptitude, synaptic, app-install ultra rapide avec une gestion des dépendances impeccable
- mise en veille fonctionnelle
- communauté très active, une documentation française sur ubuntu-fr très large.
- une sortie tous les 6 mois, avec un système de mise à jour vers la version supérieure en 1 clic.
[^] # Re: Cas complexes
Posté par ecyrbe . En réponse au journal Résolution des dépendances par système de branches. Évalué à 0.
Sinon, si E n'est pas une autre version de B, je ne vois pas pourquoi on devrait parcourir la base pour trouver une solution à l'action de l'utilisateur... dans ce cas on ne devrait que lui présenter l'information du conflit et pas d'autre solution que de désinstaller B.
# VirtualBox
Posté par ecyrbe . En réponse au journal Un petit tour sur le paysage de la virtualisation Linux. Évalué à 4.
VirtualBox : pratique pour virtualiser un desktop PC, il a l'avantage d'être facile à paramétrer et à utiliser pour l'utilisateur final. Les dernières versions font état du support d'openGL directement sur la machine embarqué.
[^] # Re: Un peu précipité, non ?
Posté par ecyrbe . En réponse à la dépêche Processeur graphique : NVIDIA est mal parti pour les années à venir. Évalué à 4.
il y a une pelleté d'application a ces domaines :
- traitement de l'image
- simulation de problèmes physiques (météo, big bang, aéronotique ...)
- mathématiques vectorielles/matricielles
- analyse spectrale
# RocketMet
Posté par ecyrbe . En réponse à la dépêche Paquet de petites brèves d'été (la suite). Évalué à 1.
c'est pas si secret que ça, vu qu'on a une news dessus...
[^] # Re: heu...
Posté par ecyrbe . En réponse à la dépêche Microsoft Office interdit aux USA ?. Évalué à 10.
[^] # Re: Déçu
Posté par ecyrbe . En réponse à la dépêche Retard(s) pour la prochaine version de C++. Évalué à 4.
Non, ça n'as rien a voir... QtDesigner tout comme Glade, c'est plutôt ce qu'on appelle du RAD (Rapid Application Developpement) avec un système de déclaration des widgets.
Pour voir ce qu'est du Déclarative UI voici un lien vers le projet de Qt :
http://labs.trolltech.com/blogs/category/labs/graphics/kinet(...)
[^] # Re: Déçu
Posté par ecyrbe . En réponse à la dépêche Retard(s) pour la prochaine version de C++. Évalué à 2.
Sinon, Il y a Glade pour Gtk/Gtkmm et le nouveau loadeur GtkBuilder... mais il s'agit plus de RAD que de langage déclaratif ici.
[^] # Re: Déçu
Posté par ecyrbe . En réponse à la dépêche Retard(s) pour la prochaine version de C++. Évalué à 8.
Mais je n'ai rien contre Ocaml, ce n'est juste pas un remplaçant à c++ à mes yeux.
Quand à ta comparaison Ocaml vs C , on peut dire la même chose C++ vs C
Et je trouve qu"écrire des interface graphiques, des serveurs asynchrones, faire de la programmation parallèle etc, ce n'est pas le fort d'ocaml si on le compare à C++
Ce n'est donc pas une attaque, mais pour le code de mes productions, je ne mettrais jamais de Ocaml. Mais ce n'est que mon point de vue, et peut être ai-je tord.
[^] # Re: Déçu
Posté par ecyrbe . En réponse à la dépêche Retard(s) pour la prochaine version de C++. Évalué à 5.
Ocaml répond à certains besoins, mais j'avoue que pondre une interface graphique avec du langage fonctionnel, même s'il supporte des paradigmes impératif est une vrai plaie...
Par contre pour pondre des algorithmes, un compilateur etc... j'avoue qu'ocaml est au dessus du lot!
# Déçu
Posté par ecyrbe . En réponse à la dépêche Retard(s) pour la prochaine version de C++. Évalué à 9.
Je programme en C++ sur 90% de mon code... et 10% de C.
Les templates, et particulièrement celles de la Stl, Boost ou gtkmm et consorts génèrent des erreurs difficiles à diagnostiquer.
Avec mon expérience, maintenant je décrypte ces erreurs très vite, mais il m'a fallu accumuler une grosse expérience pour acquérir des automatismes à ce niveau là.
Du coup, quand il s'agit d'embaucher un développeur c++, prendre des débutants est un choix risqué, car je sais que je vais devoir passer énormément de temps à l'encadrer et lui expliquer comment trouver les sources d'erreurs... la productivité s'en retrouve bien vite plombée.
J'attendais donc les concepts avec une grande impatience. même si je suis ravi qu'il y ait l'inclusion du mot clef "auto" et les fonctions "lambda", c'est une fonctionnalité indéniablement utile pour le débutant qui vient de sauter.
ça me laisse un peu perplexe, et encore plus le fait que le standard se voit repoussé.
Le comité de standardisation semble empêtré dans des débats interminable. Ils avancent à une vitesse d'escargot! Les techno c++ commencent à accumuler un retard considérable.
Attendre encore 5 à 7 ans pour voir l'inclusion des concepts dans le c++ me semble être un avis de décès pour ce langage.
J'attends encore un remplaçant convainquant, car D ne m'a pas encore séduit... même s'il a beaucoup d'atouts, il lui manque aussi les concepts et il y a encore trop peu de bibliothèques disponible à mon goût.
Pour faire du code dépendant de la plateforme GLib, j'envisage d'approfondir mon étude de Vala, même s'il n'y a pas de templates mais plutôt des Generics comme en Java. Cependant ce langage est encore trop jeune pour passer en production de mon point de vue.
[^] # Re: Phase II
Posté par ecyrbe . En réponse au journal Microsoft sort un pilote Linux sous GPL. Évalué à 5.
Je crois qu'on est plutôt dans la transition III vers IV qui va durer très longtemps à mon avis...
[^] # Re: .
Posté par ecyrbe . En réponse au journal SmartEiffel RIP. Évalué à 3.
C'était mon professeur quand j'étais en école d'ingénieur, et c'est un type que j'ai toujours apprécié, super balèze, il nous a initié à smarteiffel (smalleiffel à l'époque), m'as appris beaucoup de choses et était vraiment à l'écoute de ses élèves.
Pour l'ambiance qui règne dans l'équipe, je dirais qu'elle doit être bonne, en tout cas à l'époque l'ambiance était au beau fixe car son projet était vraiment innovant.
Franchement, le connaissant, je pense qu'il a essayé d'améliorer Eiffel, de toute bonne foi.
Je pense qu'effectivement la rétro-compatibilité n'était pas son but premier, mais améliorer le language, expérimenter de nouvelles méthode d'optimisations etc...
Ne l'oublions pas, Dominique Colnet est un chercheur, il aime les défis, et répondre aux critiques ne doit pas être son passe temps favoris...
[^] # Re: J'ai du mal à comprendre un truc...
Posté par ecyrbe . En réponse au journal Incertitude autour d'OpenSolaris. Évalué à 5.
La version opensolaris permet à sun (et donc maintenant oracle) d'avoir des beta testeurs, une communauté qui peut découvrir des problèmes et proposer des solutions etc.
OpenSolaris permet donc à Solaris d'être plus stable, ça rapporte indirectement, sans compter que ça permet le marketing viral. Un utilisateur content de son OpenSolaris pourra faire du lobbying dans sa société pour que sa direction installe du Solaris...
Je pense donc que ce serait un mauvais pari pour oracle de fermer Opensolaris.
[^] # Re: GTK+ va-t-il peut-être pouvoir concurrencer Qt un jour ?
Posté par ecyrbe . En réponse au journal Gtk+ client side windows merge. Évalué à 4.
Ouais, enfin Qt 4.4 est sortis l'année dernière en Mai... un an et demi de retard c'est pas quelques années! Le troll est un peu poilu, non?
De plus à la sortie en septembre, tous les backend seront supportés aussi, il n'y a qu'à voir les patch d'aujourd'hui et d'il y a 4 jours... il s'agit du portage des backends win32 et directFB... il me semble que mac avance sur un projet séparé et que les merges se font moins souvent.
[^] # Re: Gtk+ et l'accessibilité
Posté par ecyrbe . En réponse au journal Gtk+ client side windows merge. Évalué à 4.
Donc, déjà ouvre un compte, tu verra son adresse e-mail (en tout cas, moi je la vois).
Ensuite, s'il te plait, évite de lui écrire si tu n'as pas de code à fournir ou une mise a jour du patch déjà proposé envers la branche courante de developpement (git clone est t'on amis). Je t'assure qu'ils sont débordés, si tu veux faire avancer ce bug, il faut arriver avec quelque chose pour lui décharger au maximum le travail.
Si tu n'arrive pas à joindre Christian (ce qui expliquerais pourquoi le bug stagne), essaye de contacter matthias classen, mais encore une fois, il te faut proposer quelque chose, un patch tout fait et testé... il pourra peut être faire débloquer la situation (attention, matthias est encore plus débordé que d'autres, donc y aller mollo)
[^] # Re: Gtk+ et l'accessibilité
Posté par ecyrbe . En réponse au journal Gtk+ client side windows merge. Évalué à 2.
Cependant, j'en vois qui datent de début mai... donc oui certains sont peu être traités rapidement, mais pas tous...
[^] # Re: Gtk+ et l'accessibilité
Posté par ecyrbe . En réponse au journal Gtk+ client side windows merge. Évalué à 7.
Personnellement, je n'ai pas le temps de devenir mainteneur, je préfère soumettre des patchs. Envoyer 4 ou 5 mails pour un patch ce n'est pas la mort comparé à en recevoir des centaines tout en faisant avancer le code qu'on doit pondre sur d'autres projets.
D'autant plus qu'en attendant, je garde une version de gtk avec mes patchs, j'en ai encore quelques un qui ne sont pas appliqués, ça ne me dérange pas outre mesure, vu que je suis en mesure d'utiliser ma propre version.
Je soumet mes patchs pour en faire profiter le plus grand nombre, mais je garde à l'esprit qu'ils ne sont pas forcément du gout de tout le monde, mais parfois j'obtiens le soutiens de quelqu'un qui en a besoin, et ça permet à des patch de rentrer dans la version officielle.
Je pense que ce n'est d'ailleurs pas qu'un problème de Gtk, sur le kernel, réussir à soumettre un patch me semble bien plus difficile, bien que je n'ai jamais essayé.
Sur Qt on peut en soumettre depuis peu et un collègue qui bosse avec moi à déjà soumis des patchs, mais on lui a dis qu'ils ne pourront pas être intégrés avant quelques mois faute de temps...
Bref ça depend de la priorité que les mainteneurs affectent au patch, à la taille de l'équipe de mainteneurs, à la qualité du code fournis, à la volonté de celui qui soumet le patch de le voir intégrer.
c'est ça le travail communautaire.
[^] # Re: Gtk+ et l'accessibilité
Posté par ecyrbe . En réponse au journal Gtk+ client side windows merge. Évalué à 3.
Mon expérience est qu'à chaque fois que j'ai voulu faire appliquer un de mes patch, comme je ne suis pas mainteneur officiel de gtk, j'ai fait un peu de lobbying auprès du mainteneur concerné par mail pour qu'il l'applique. Ils ont beaucoup de boulot et donc souvent ils te disent ok si tu trouve quelqu'un pour faire un review de ton patch. ce que j'ai fait en postant sur la mailing list ou en demandant directement à mattias s'il pouvait y jeter un oeil.
une fois que t'as un feu vert, tu fait le forcing auprès d'un mainteneur pour qu'il applique le patch vu que t'as obtenu le feu vert (que tu met en copie)...
[^] # Re: À quand la possibilité d'utiliser Gtk avec Wayland ?
Posté par ecyrbe . En réponse au journal Gtk+ client side windows merge. Évalué à 3.
En effet, gtk+ 2.17.4 (dernière version taggé) peut être installé en parrallèle avec la version stable, à condition de l'installer dans /usr/local/ et non /usr.
pour celà un petit ./configure --prefix=/usr/local puis make puis make install suffira
# specifications
Posté par ecyrbe . En réponse au journal Beta RHEL 5.4. Un non évènement pour le libre ?. Évalué à 4.
Ou bien ce n'est pas encore publié?
Y a t'il eut une communication de Redhat sur les brevets qu'ils detiennent sur SPICE après le rachat de Qumranet?
[^] # Re: Ubuntu
Posté par ecyrbe . En réponse au message Changer de distribution mais laquelle ?. Évalué à 1.
[^] # Re: Fedora
Posté par ecyrbe . En réponse au message Changer de distribution mais laquelle ?. Évalué à -1.
Il n'a pas dit qu'il n'y avait pas des bogues avec certains drivers...
D'ailleurs on remarquera que souvent les problèmes sont dus à des drivers proprios (pas toujours en plus) qui font mal leur boulot...
Mais de là dire qu'il ment en prétendant qu'il y a une hibernation fonctionnelle sous Fedora, ce n'est pas un mensonge, tout au plus un manque d'exhaustivité car il n'a pas listé les drivers qui pourraient poser problème.
Mais sa réponse aurait été un peu trop longue.
Le posteur demande des idées de distribution.
Les gens lui proposent, il en fait ce qu'il veut, voir il peu se renseigner un peu plus avant de sauter le pas...
[^] # Re: Ubuntu
Posté par ecyrbe . En réponse au message Changer de distribution mais laquelle ?. Évalué à 0.
mais alors vraiment jamais... c'est pour ça qu'il n'y a jamais le moindre retour de bogue des autres distribution...
Je rigole devant la naïveté des FUDs qui sont lançés à l'encontre d'Ubuntu...
[^] # Re: Ubuntu
Posté par ecyrbe . En réponse au message Changer de distribution mais laquelle ?. Évalué à 2.
Maintenant dis moi le nom de ta distribution et on verra si personne ne se plaint de problèmes d'hibernation, juste pour rire un peu...
# Ubuntu
Posté par ecyrbe . En réponse au message Changer de distribution mais laquelle ?. Évalué à 1.
- Installation graphique avec un live CD super rapide
- Un chargement rapide grâce à UpStart
- Une installation simplifié des drivers proprios
- Une installation guidée des codecs à la demande
- Un nombre de paquets aussi grand que Debian
- le système de paquet de debian et apt-get, aptitude, synaptic, app-install ultra rapide avec une gestion des dépendances impeccable
- mise en veille fonctionnelle
- communauté très active, une documentation française sur ubuntu-fr très large.
- une sortie tous les 6 mois, avec un système de mise à jour vers la version supérieure en 1 clic.