Et bien pourtant, c'est une version extrêmement importante et lourde de sens pour tous le Gnomistes, et plus encore pour les anti-Gnomistes : après huit ans de service, cette mise à jour est la dernière de GNOME 2 qui va laisser place à GNOME 3 dès septembre prochain. GNOME 2, GNOME éternel, Toi la constante globale de l'univers linuxien, nous faudra-t-il réellement te quitter un jour ? Pourtant, c'est bien ce que nous prépare la communauté : une révérence soignée, mais une révérence quand même.
GNOME 2.30.2 ne sera pas une révolution. Il s'agit uniquement de corriger les derniers bugs importants et des fuites de mémoire. Tout comme les sous-versions précédentes. On ne peut s'empêcher de penser à ce ménage qu'on fait avant de fermer la maison dans laquelle on a passé ses vacances.
Mais peut-être faut-il être plus optimiste et considérer que les vacances ne se terminent pas, mais commencent. Il est vrai que Metacity se fait vieux et qu'il est unanimement reconnu comme limité, le Gnome-Shell qui prendra sa place laisse entrevoir un bureau en colonnes composite.
GNOME 3 sera aussi plus attachant : il s'intéressera à ce que vous faites et vous pourrez consulter votre historique dans Zeitgeist. Ses post-its Tomboy pourront se synchroniser via Internet pour que vous puissiez récupérer vos notes partout. Oui, GNOME 3 s'intéressera à vous et sera soucieux que vous vous y retrouviez. Pour ce faire, Yelp, le lecteur de manuel sera bien plus rapide, vous laissera mettre des signets sur les pages que vous considérez comme importantes et l'interface sera légèrement différente selon le document consulté.
GNOME 3 sera plus ludique, en facilitant la conversion des différents types de médias, supportant de base un certain nombre de webcams, et facilitera la configuration audio de votre système.
Oui, les vacances ne font peut-être que commencer avec GNOME 3, et qu'on rende hommage à GNOME 2 ou qu'on soit soulagé qu'il laisse sa place, on a quand même hâte de voir à quoi ressemblera la prochaine version.
Aller plus loin
- Annonce de GNOME 2.30.2 sur la liste de diffusion (11 clics)
- Annonce de GNOME 2.31.4 (branche de développment) (7 clics)
- Présentation de GNOME 3 par l'équipe GNOME (41 clics)
- Feuille de route de GNOME 3 (1 clic)
# Confusion dans les versions
Posté par Frédéric Péters (site web personnel) . Évalué à 10.
Par ailleurs, hier 1er juillet, ce n'est pas la 2.30.4 mais la 2.31.4 qui est sortie, c'est donc la quatrième version de développement de GNOME 2.31 (série qui donnera la version stable 3.0), le principal changement dans cette version est l'apparition de plus en plus de modules utilisant GTK+ 2.90 (qui donnera la version 3), avec une bonne part des bibliothèques de la pile déjà portées, et déjà quelques applications.
Pour la suite ? Ce sera une 2.31.5, prévue le 14 juillet, elle devrait voir encore plus d'applications portées vers les nouvelles bibliothèques, et puis bien sûr toujours des nouvelles versions des différents modules, dont GNOME Shell, bien sûr.
Le calendrier pour le cycle est visible ici : http://live.gnome.org/TwoPointThirtyone
[^] # Re: Confusion dans les versions
Posté par j (site web personnel) . Évalué à 3.
# Gnome ...
Posté par El Titi . Évalué à 10.
[^] # Re: Gnome ...
Posté par BAud (site web personnel) . Évalué à 8.
[^] # Re: Gnome ...
Posté par FreeB5D . Évalué à 8.
[^] # Re: Gnome ...
Posté par Mikis . Évalué à 4.
# pulseaudio
Posté par Anonyme . Évalué à 3.
# API de synchro
Posté par fredix . Évalué à 10.
Ca permettrait de plus aux applications desktop d'exploiter enfin Internet et de pouvoir concurrencer les application web, en synchronisant les données mais pourquoi pas aussi en proposant de les partager entre différent utilisateur GNOME.
J'ai l'impression que KDE a un train d'avance là dessus en travaillant sur socialdesktop.
[^] # Re: API de synchro
Posté par antistress (site web personnel) . Évalué à 6.
[^] # Re: API de synchro
Posté par fredix . Évalué à 2.
[^] # Re: API de synchro
Posté par fredix . Évalué à 2.
[^] # Re: API de synchro
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
KDE4 est en avance d'une grosse rupture de continuité. Souvenez-vous, les premières versions de KDE4 étaient à peine utilisables.
Il est à souhaiter que Gnome ne subisse pas un tel choc car KDE a fini par digérer Qt4 et est maintenant très performant. Gnome ne peut pas se permettre de refaire le calamiteux coup de KDE4.0 car la compétition entre KDE et Gnome en souffrirait, or elle est utile et nécessaire.
[^] # Re: API de synchro
Posté par Grunt . Évalué à 7.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: API de synchro
Posté par Teutates (site web personnel) . Évalué à 2.
Le danger serait alors que Gnome 3 nous refasse le même coup que KDE 4 autant par des débuts non stables que par un accroissement d'exigence en quantité de mémoire RAM.
[^] # Re: API de synchro
Posté par Grunt . Évalué à 3.
Du coup, vu que j'ai pas le temps de passer ma journée à contourner des bugs, pour l'instant j'en suis à Gnome et ça marche bien :)
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: API de synchro
Posté par Tonton Benoit . Évalué à 2.
Je me rappelle y'a pas si longtemps on en trouvais encore un dans le top 10 des projets les plus populaires sur gnomefiles ! De vrais cafards, ça refuse d'évoluer et ça survit à tout !
# Zeitgeist refusé
Posté par Olivier (site web personnel) . Évalué à 7.
Personnellement je trouve bien triste que cette technologie ne soit pas présente dès le début, ça sent le syndrome kde4. Zeitgeist est assez surprenant et j’aime bien cette « nouvelle » façon de naviguer dans ses documents (activités). Des plugins pour de nombreux éléments de gnomes arrivent (jusqu’à Getting Things Gnome, ou Hamster). Voir des outils comme sezen ou gnome-journal tourner me fait dire que c’est un mode de navigation qui m’irait assez bien (bon, je garde autojump² quoi qu’il en soit et qui mériterait d’être porté dans un navigateur graphique… comme une awesomebar du navigateur de fichier)
Ça mériterait un journal… mais j’ai des couches a changer !
[1] la réaction d’un des dev : [http://seilo.geekyogre.com/2010/06/my-take-on-zeitgeist-and-(...)]
[2] pas assez de pub autour de cet outil génial dont le dev est ici, sur linuxfr, et qui m’est un indispensable de la console : [http://wiki.github.com/joelthelion/autojump/] d’autant qu’il semble que le développement se poursuive.
[^] # Re: Zeitgeist refusé
Posté par Loic Dreux . Évalué à 6.
[^] # Re: Zeitgeist refusé
Posté par O'neam Anne . Évalué à 0.
Sinon, Zeitgeist, il y a des chances pour que ta distribution l'installe directement, aussi.
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
[^] # Re: Zeitgeist refusé
Posté par rikoukiki . Évalué à 4.
http://seilo.geekyogre.com/2010/04/docky-love/
[^] # Re: Zeitgeist refusé
Posté par O'neam Anne . Évalué à 1.
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
[^] # Re: Zeitgeist refusé
Posté par Albert_ . Évalué à 2.
[^] # Re: Zeitgeist refusé
Posté par O'neam Anne . Évalué à 2.
La grande roue karmique…
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
[^] # Re: Zeitgeist refusé
Posté par Albert_ . Évalué à 1.
[^] # Re: Zeitgeist refusé
Posté par O'neam Anne . Évalué à 2.
Par exemple, chez les Sikhs.
Ainsi, en étant maudit sur 10 générations, j'ai de fortes chances d'être ré-incarné au moins 9 fois.
Ce qui est vraiment la plaie !
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
[^] # Re: Zeitgeist refusé
Posté par Christophe Turbout . Évalué à 3.
la liste des informations ouvertes relatives à ton appli où bien le truc immonde à la mac qui est le bureau ?
car si c'est ça le bureau gnome 3 perso je change de suite !
je suis comme une poule mouillée devant un mac ... je préfère encore windowmaker c'est dire !
[^] # Re: Gnome 3 refusé
Posté par Zarmakuizz (site web personnel) . Évalué à 3.
http://www.linuxcertif.com/news/breve/00268/
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Gnome 3 refusé
Posté par Stéphane Démurget (site web personnel) . Évalué à 6.
<mode detection lien trollant ON>
Déjà un article qui commence avec copier Plasma et Nepomuk, c'est un peu n'importe quoi :
- gnome-shell est une appli, pour un desktop sans fioriture, justement anti-gadget, et plasma une librairie pour faire des gadgets !
- gnome 3 ne veut pas de web sémantique dans un premier temps (zeitgest refusé), et Tracker (dépendance externe) utilise les ontologies Nepomuk au lieu de réinventer la roue
<mode detection lien trollant OFF>
Sinon je ne vois pas de quoi il va être amputé ? Les changements majeurs de Gnome 3 :
- gnome-shell
- nettoyage du code en consolidant l'API de certaines bibliothèques dans Gtk-3 directement
Dans KDE 4, il y a eu beaucoup de changement au niveau des librairies (qui sont géniales d'ailleurs) : il a fallu du temps pour les applications majeures afin d'être portées.
Gnome-shell est une application, pas un framework comme plasma et Kde 4. Il n'y a rien à porter du tout !
Gnome 3 est aussi l'occasion d'un gros nettoyage de code : au niveau des API supprimées (recommandées mais on peut utiliser Gtk2), et celles ajoutées (GSettings par exemple, mais c'est optionnel). Bien sûr un effort est fait pour que toutes les applis utilisent enfin des APIs propres et récentes, mais si ce n'est pas fait tout marchera comme avant.
Cette phase de nettoyage avec Gtk3 c'est justement pour enfin faire de vrais changement dans Gtk 3.2 :)
Après gnome-shell, on aimera ou on aimera pas, et dans ce cas là l'ancien panel et desktop seront toujours là pour ceux qui ne veulent pas changer. Dans tous les cas les applications auront évoluées en attendant.
Par rapport aux design initial : http://www.gnome.org/~mccann/shell/design/GNOME_Shell-200911(...) on est pas si loin que ça (manque qd même pas mal de trucs sur les ).
[^] # Re: Gnome 3 refusé
Posté par Zarmakuizz (site web personnel) . Évalué à 2.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Gnome 3 refusé
Posté par collinm (site web personnel) . Évalué à 0.
www.solutions-norenda.com
[^] # Re: Gnome 3 refusé
Posté par patrick_g (site web personnel) . Évalué à 2.
Ils seront toujours là ad vitam aeternam ou juste pendant un certain temps pour que les gens "s'habituent" à Gnome Shell et qu'on puisse les virer ?
Moi j'ai peur que dans 2 ou 3 ans on nous annonce la suppression du panel/desktop.
[^] # Re: Gnome 3 refusé
Posté par gnumdk (site web personnel) . Évalué à 3.
>panel/desktop.
C'est ce qui est prévu, en tout cas ce que m'on dit des devs sur #gnomefr ;)
Après, c'est une question d'habitude, et peut être que le panel gnome-shell sera moins rigide avec le temps.
[^] # Re: Zeitgeist refusé
Posté par Stéphane Démurget (site web personnel) . Évalué à 2.
Pour l'inclusion, le développeur principal proposait une application qui est complètement indépendante, et qui n'est pas passée par une revue ergonomique, ne ne s'est pas rapprochée des équipes de traduction et documentation. Il a prit ça pour un refus surtout lié à l'hébergement sur launchpad (c'est vrai que c'est dommage, surtout pour les traductions).
C'est qd même gênant pour un desktop qui depuis quelques années essait un max d'avoir un environnement homogène et bien intégré.
[^] # Re: Zeitgeist refusé
Posté par Olivier (site web personnel) . Évalué à 4.
En y pensant je me dit malgré tout qu’intégrer le moteur aurait été intéressant pour que, le jour ou l’intégration dans les logiciels soit effective, on ait un peu de recul au niveau des logs de zeitgeist (oui, j’admet, c’est un peu tordu, mais zeitgeist sans historique, ça ne sert à rien).
Et puis zeitgeist manque encore d’un « porn-mode » qui permettrait de le désactivé quand on ne veut pas « polluer » son historique. C’est prévu mais je n’ai pas encore vu de système pour en effet mettre zeitgest en pause.
[^] # Re: Zeitgeist refusé
Posté par zebra3 . Évalué à 2.
Bah y'a ça :
$ zeitgeist-daemon --quit
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Zeitgeist refusé
Posté par Mildred (site web personnel) . Évalué à 1.
On peut aussi assumer ses tendances et ne pas en avoir honte. Et si on est vraiment schizophrène, on peut aussi créer un compte utilisateur additionnel (j'ai bien fait un compte sandbox pour utiliser skype). Mais de toute façon, il me semble que Firefox à déjà un mode "private browsing".
Mais c'est vrai que ça peut être utile pour plein de choses de pouvoir désactiver Zeitgeist, pas juste le porn :)
# Virez-nous Metacity et le gestionnaire d'aide
Posté par marahi . Évalué à 8.
Vivement Gnome 3 !
[^] # Re: Virez-nous Metacity et le gestionnaire d'aide
Posté par Zarmakuizz (site web personnel) . Évalué à 3.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Virez-nous Metacity et le gestionnaire d'aide
Posté par Stéphane Démurget (site web personnel) . Évalué à 2.
Pour l'aide, yelp utilise gecko pour Gnome 2, mais il utilise webkit dans la version de Gnome 3 et pour avoir testé ça démarre beaucoup plus vite.
Par contre, je ne pense pas qu'il y ait beaucoup de documentation au format Mallard, qui devient un peu plus "pratique", plutôt que d'avoir une simple description des champs de l'appli qui ne sert pas à grand chose.
[^] # Re: Virez-nous Metacity et le gestionnaire d'aide
Posté par zebra3 . Évalué à 2.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Virez-nous Metacity et le gestionnaire d'aide
Posté par Frédéric Péters (site web personnel) . Évalué à 2.
[^] # Re: Virez-nous Metacity et le gestionnaire d'aide
Posté par antistress (site web personnel) . Évalué à 1.
Mutter c'est une grosse évolution, basée sur Clutter
[^] # Re: Virez-nous Metacity et le gestionnaire d'aide
Posté par nicko . Évalué à 1.
# ...
Posté par She0gorath . Évalué à 5.
je ne savais aps que ce truc allait être intégré à gnome3. J'ai bien fait de passer à wmii, moi !
Bon, trève de troll, c'est quand-même bien que gnome change enfin de version en septembre. Je testerait.
[^] # Re: ...
Posté par Loic Dreux . Évalué à 2.
[^] # Re: ...
Posté par zebra3 . Évalué à 2.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: ...
Posté par Gabin . Évalué à 8.
Thomboy ? C'est pas ce truc en mono horrible que je désinstalle en premier ?
Aller faisons un petit effort, et disons-nous que Mono c'est bien, qu'est-ce que ça nous a apporté, au libre, je veux dire?
L'ecosystème mono est fourni de combien de logiciels si "cool" qu'ils n'auraient pas pu être developpés avec un autre langage/platforme?
L'interopérabilité avec les applis .NET? des exemples?
Qu'est-ce qui justifie l'existence de Mono mais et surtout l'intégration à Gnome? Alors que ce bureau dispose d'API Python, Perl, Ruby et d'autres j'imagine...
Honnêtement, je ne veux même pas "troller" à ce sujet, je veux juste comprendre la plus value.
[^] # Re: ...
Posté par Loic Dreux . Évalué à 2.
Le simple fait qu'il y ai des développeur .Net justifie Mono.
[^] # Re: ...
Posté par Obsidian . Évalué à 9.
(Ok, pataper /o\, je sors tout seul →[]).
[^] # Re: ...
Posté par houra . Évalué à 3.
Une implémentation du langage C# en Java , ça serait pas mal par contre. :)
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: ...
Posté par yellowiscool . Évalué à 3.
Ça ne protégerais pas plus juridiquement que l'implémentation mono, et en plus, la machine virtuelle mono est pas mal :
http://shootout.alioth.debian.org/u32q/benchmark.php?test=al(...)
Envoyé depuis mon lapin.
[^] # Re: ...
Posté par houra . Évalué à 2.
Tiens, ça me fait penser à ce que disait Microsoft à l'époque d' OS/2 :
" Nous, vouloir couler OS/2 ? Certainement pas, pour chaque OS/2 vendu, IBM nous reverse cinq fois ce qu'on obtiendrait en vendant nos propres licences !" ( ref nécessaire ^^ )
Par contre, si on pouvait profiter de la puissance de NetBeans et Eclipse pour Vala ou pour un langage sur runtime ressemblant à C#, là, oui, ça serait porteur.
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: ...
Posté par zebra3 . Évalué à 5.
Je dirais plutôt, pourquoi pas Mono, puisqu'on conserve bien Python, Perl ou Ruby ? En quoi ceux-ci sont plus légitimes que Mono ? Après tout, il y a déjà GTK.
Bref, laisser les développeurs employer les langages et frameworks qu'ils connaissent et apprécient, et si vous n'êtes pas contents, ne les utilisez pas, point.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: ...
Posté par FreeB5D . Évalué à 7.
Parce que le .NET sapusépalibre et de plus sécontroléparmicromousapulesbrevetslogiciels .
[^] # Re: ...
Posté par zebra3 . Évalué à 3.
Les technologies à la base de Mono, soumises à l'ECMA, ne sont pas problématiques. Ceci inclut aussi la couche de compatibilité Mono/Linux/GNOME, qui n'utilise pas des technologies pouvant être couvertes par des brevets de Microsoft. Donc, C#, les bibliothèques et autres couches logicielles du projet GNU ne sont pas concernés par ces préoccupations.
Les seuls composants pouvant poser problèmes sont ceux de la couche de compatibilité Microsoft, ce qui fait que tous les projets uniquement pour Linux sont parfaitement sûrs.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: ...
Posté par BAud (site web personnel) . Évalué à 4.
cf. http://fedoraproject.org/wiki/ForbiddenItems#Moonlight
[^] # Re: ...
Posté par Gabin . Évalué à 5.
Donc Mono n'a pas été créé dans un soucis d'interopérabilité afin de ne pas se voir larguer par Microsoft qui auraît imposé sa platforme à l'univers. J'ai pourtant cru voir que l'interopérabilité était l'argument premier à l'époque!
Donc dans les faits:
On voit que c'est inutile car une appli Mono (porte bien son nom tiens finalement :p ) est seulement réservé à Linux/Unix sous peine de... peines.
Ensuite, ils ont tout simplement présumé des forces de Microsoft à dépasser Java.
Je veux bien sortir le discours "politiquement bisounours", on est libre, la force du LL c'est la diversité, patati, patata... Mais là franchement, c'est de l'argent, du temps gaspillé et des CONTRAINTES en plus pour une chose dont la priorité pour l'écosystème du libre n'était vraiment, mais vraiment pas nécessaire!
Cela étant, je ne dis pas détenir le savoir, donc si des arguments peuvent m'éclairer et étendre un plus l'ouverture de mon esprit, svp, faites.
[^] # Re: ...
Posté par zebra3 . Évalué à 5.
Le vrai gaspillage de temps, c'est de les réécrire en C ou autre, comme GNote qui a un train de retard sur Tomboy.
Le fait est que des gens aiment développer en Mono, et d'autres apprécient les logiciels qui en découlent, c'est tout ce qui compte. J'utilise Tomboy et F-Spot, non parce qu'ils sont en C#, mais parce que je les trouve bien conçus.
Pourquoi faut-il toujours se justifier ? Encore une fois, vous n'aimez pas, ne les utilisez pas et puis c'est tout.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: ...
Posté par gnumdk (site web personnel) . Évalué à 7.
C'est le gaspillage de temps CPU...
[^] # Re: ...
Posté par Stéphane Démurget (site web personnel) . Évalué à -4.
Honnêtement ça fait 10 ans que je bosse avec Java, et je comprends forcément ceux qui font du Python, du Mono ou même aimerait faire du Java : retourner au C ou C++ c'est juste une perte de temps et de qualité extraordinaire, vraiment.
Il n'y a que ceux qui n'ont pas fait les deux au moins 2 ans qui ne peuvent pas comprendre.
C'est sûr il y a 10 ans, je contribuais à Gnome, et j'aimais faire du C ou du C++. Mais sérieusement on est en 2010 !
Python c'est aussi assez lent à lancer, même une appli bien faite (enfin c'est d'un autre ordre que Mono et Java tout de même). Je trouve Python super adapté aux applis de configuration (pas trop grosses, qui peuvent changer souvent). Par contre refactorer et maintenir du code à long terme c'est compliqué (pas d'outils sympa pour refactorer).
Peut-être que la vraie alternative c'est Vala, même si bien sûr on perd les avantages de Mono et Java : debug fastoche, profiling fastoche, refactoring en 2s, compilation supra rapide, IDEs de grande qualité, etc. Et puis déjà qd Mono comme tu dis il n'y a pratiquement rien, alors en Java c'est le désert total.
On gagne quand même sur le principal : l'écriture, la simplicité du code, et la gestion des références.
C'est sûr sous Windows, les librairies .Net sont partie intégrante du système, alors c'est déjà bien plus rapide, et ça on ne l'aura jamais sous Gnome :p
bordel, pourquoi il n'y a pas une solution qui déchire dans tous les coins, on pourrait écrire des trucs de malades en 2s :'(
[^] # Re: ...
Posté par Lutin . Évalué à 10.
[^] # Re: ...
Posté par claudex . Évalué à 9.
Et alors? On ne peut pas écrire de code en C les années qui contiennent le chiffre 1?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ...
Posté par Gabin . Évalué à 7.
C'est sûr il y a 10 ans, je contribuais à Gnome, et j'aimais faire du C ou du C++. Mais sérieusement on est en 2010 !
Et alors? On ne peut pas écrire de code en C les années qui contiennent le chiffre 1?
Il veut simplement dire que Gnome n'a pas evolué en 10 ans.
--->[]
[^] # Re: ...
Posté par Kerro . Évalué à 3.
J'ai utilisé les deux. Ce que j'en sais: Java est l'équivalent d'un sous-ensemble de C++. On peut (à quelque chose près) traduire mot à mot du Java vers du C++, mais pas l'inverse.
[^] # Re: ...
Posté par Antoine . Évalué à 3.
Ah, oui, c'est bien connu: C++ fournit un ramasse-miettes.
[^] # Re: ...
Posté par Kerro . Évalué à 4.
"Les programmeurs Lisp savent que la gestion de la mémoire est si importante qu'elle ne peut être laissée aux programmeurs. Les programmeurs C savent que la gestion de la mémoire est si importante qu'elle ne peut être laissée au système" (Bjarne Stroustrup)
Compter sur le ramasse-miettes pour q'un programme fonctionne, c'est comme jetter ses déchets par la fenêtre de son automobile: pas besoin de savoir ce que ça génère, les autres sont là pour s'en occuper.
[^] # Re: ...
Posté par collinm (site web personnel) . Évalué à 4.
tu prends à peu près n'importe qu'elle logiciel, tu regardes ses mises à jour et il y aura eu des correction au niveau de la mémoire...
www.solutions-norenda.com
[^] # Re: ...
Posté par yellowiscool . Évalué à 2.
Si un logiciel a une fuite de mémoire, chose plutôt courante (surtout sur gnome), il peut consommer plus de mémoire que ce dont il a besoin. Peut-être 15Mo de trop, au bout de quelques semaines (une fuite énorme est rapidement détectée).
Si un logiciel équivalent est écrit avec un ramasse miettes de merde, il va consommer dés le début 120Mo de trop, sans amélioration possible.
Les erreurs de corruption de la mémoire quant à elle sont plutôt rare, car si le logiciel est correctement testé, ça plante à la figure, et un débuggeur insulte assez correctement les developpeurs.
Envoyé depuis mon lapin.
[^] # Re: ...
Posté par Antoine . Évalué à -1.
Tout l'intérêt du ramasse-miettes intégré au langage, c'est qu'au lieu d'avoir un "ramasse-miettes de merde" spécifique à chaque logiciel un peu compliqué, tu as une plateforme commune qui est relativement mûrie et débuggée, et bien réglée (ou réglable, d'ailleurs).
C'est comme un compilateur : ça abstrait et mutualise un travail fastidieux (la traduction d'instructions haut niveau en code assembleur) au prix d'une petite perte potentielle d'efficacité par rapport à l'écriture d'une gestion bas niveau écrite à la main.
Après il y a toujours des inconditionnels de l'écriture d'ASM à la main mais, s'ils étaient encore nombreux dans les années 90, ils sont totalement marginaux aujourd'hui et font figure (fort compréhensiblement) de gentils zozos.
Les erreurs de corruption de la mémoire quant à elle sont plutôt rare, car si le logiciel est correctement testé, ça plante à la figure, et un débuggeur insulte assez correctement les developpeurs.
N'importe quoi. Correctement testé ne veut pas dire que tous les cas de figures sont prévisibles, et exhaustivement énumérables (sauf logiciel très simple). C'est d'autant plus le cas si le logiciel est multithreadé, d'ailleurs, à cause des problèmes très subtils que cela peut entraîner.
Dans le cas de Python, on trouve encore aujourd'hui des problèmes de gestion mémoire sur du code écrit parfois il y a 10 ou 15 ans. Je parle évidemment de l'interpréteur Python, plus précisément de la partie écrite en C... Après, libre à toi de penser qu'on fait de la merde et que tu es plus compétent.
[^] # Re: ...
Posté par yellowiscool . Évalué à 1.
En C++, on peut gérer manuellement la mémoire si on a envi de faire le pro, on peut utiliser les pointeurs intelligents qui sont une alternative intéressante aux ramasses miettes (plus d'opérations, mais plus de constances et pas de consommation mémoire inutile), on peut utiliser un ramasse miettes, ou tout autre système.
Sinon, depuis des années, il y a eu des progrès énormes en termes de débuggeur, notamment avec Valgrind. Ça ne permet pas de détecter toutes les erreurs, mais c'est une énorme avancée à mon avis (en même temps, j'ai commencé à coder après la création de valgrind).
Au niveau du multi-threading, on est d'accord que tout les problèmes sont impossibles à détecter. Mais je ne vois pas ce que peut apporter un ramasse miettes là dedans, à part peut-être prolonger la durée de vie de certains objets, mais ça ne fait que cacher une erreur de conception.
Envoyé depuis mon lapin.
[^] # Re: ...
Posté par Antoine . Évalué à 2.
Oui, on peut (« si on a envie de faire le pro », ce qui résume bien la motivation principale : je veux rejouer la bonne vieille légende du programmeur bas niveau qui maîtrise tout et écrit son gestionnaire mémoire à la main).
On peut aussi faire de l'assembleur pour s'affranchir de l'ABI imposée par le C, ou faire du passage de continuations, ou inventer sa propre représentation de nombres à virgule flottante.
La question, c'est de savoir pourquoi on aurait besoin de le faire (mis à part la motivation citée plus haut, toute psychologique). Et là, pour 99% des applications, il n'y a aucune réponse, parce qu'une gestion automatique conviendrait parfaitement et ferait de plus gagner énormément de temps d'écriture de code et de mise au point.
[^] # Re: ...
Posté par PachaFonk . Évalué à 2.
[^] # Re: ...
Posté par Gniarf . Évalué à 5.
par exemple, Great Circle par Geodesic Systems, qui avait énormément interessé Sun, au point de la coller dans sa JVM
[^] # Re: ...
Posté par Antoine . Évalué à -1.
Sinon, C aussi dispose d'un ramasse-miettes si on ajoute les bonnes bibliothèques.
[^] # Re: ...
Posté par Gniarf . Évalué à 3.
car tu pouvais utiliser cela et continuer à programmer proprement et méthodiquement tes desallocations et autres destructeurs, si tu voulais
et comme tu le dis toi-même, on n'a pas attendu 1995 et Java pour ne plus se casser la tête avec la mémoire. ni même 2010.
[^] # Re: ...
Posté par Antoine . Évalué à 4.
Un problème culturel peut-être ?
Ou peut-être, vraiment, le fait que ce n'est pas supporté en standard est-il un gros frein à l'adoption... Ce qui apporterait de l'eau à mon moulin.
[^] # Re: ...
Posté par Gniarf . Évalué à 2.
ah, si, les accesseurs. CA, c'est ridicule.
sinon le reste c'et un peu comme les girafes ou les chinois, ce n'est pas parce que tu n'en vois pas dans ton pays qu'ils n'existent pas ou que ce sont des zozos marginaux
un problème culturel ? faut aller à la ville, des fois...
[^] # Re: ...
Posté par Jul (site web personnel) . Évalué à 2.
La culture change antoine
En 10 ans la lib boost est apparue, elle devient un standard de fait, et ressemble au CPAN sous stéroïdes. Elle semble assez utilisée
J'ai aussi vu des devs C utilisant la lib C python afin d'utiliser les objets évolués et leurs garbage collectors (mais je trouve ça un peu porcasse).
Mais bon, à part en logiciel libre ou les gens développent parfois plus pour se faire plaisir que par efficacité, il faut admettre que le C et le C++ sont un peu tombés en désuétude. Dans mon enfance il y avait les chevaliers du zodiaque, et adulte dans le libre les chevaliers du C. Cette façon que l'on a de mouiller sur le C pur (hors noyau) me laisse perplexe.
En plus les binding haut niveau python/perl/ruby C existent ...
Si je devais recoder bas niveau, j'utiliserais ça :
http://ooc-lang.org/
* langage pivot compilant en C
* garbage collector
* gestion des modules
* objet
* élégant :)
[^] # Re: ...
Posté par barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ...
Posté par Antoine . Évalué à 3.
Le fait est que Java est un langage dont les allocations et désallocations sont gérées en standard par un ramasse-miette, ce qui rend la programmation Java fondalement différente de la programmation C++. Que ce soit lent ou pas n'est pas la question.
(ensuite, je ne connais pas les implémentations Java, mais j'imagine que 10 seconde pour une collection complète, c'est sur des jeux de données sacrément costauds, ou des applis complètement mal écrites)
[^] # Re: ...
Posté par ze_lionix (site web personnel) . Évalué à 4.
J'ai taté du processus java avec un foot print mémoire de 2.5 Go, du XmX poussé a 8 Go ( si c'est possib' ) qui partaient en 20 minutes et mettais dans les 30 à 40s sur un full GC ! Oui ca existe ! Oui y en avait besoin ! Oui c'était optimisé...( sigh )
Le problème très souvent du dev Java c'est qu'il recycle pas ses objets et se fiche notoirement de la mémoire, se reposant un peu trop sur le GC...... Et en activant les options +XX qui vont bien sur la jvm tu sors des graphiques de dérive mémoire et des stats de gc qui font mal, et tu dois mettre des baffes....
Et souvent je me disais / me dis que les dev java devraient soient
- faire un stage de C / C++
- soit avoir des machines avec 1Mo de RAM max
Fuse : j'en Use et Abuse !
[^] # Re: ...
Posté par Gniarf . Évalué à 3.
à un tout autre niveau pour les débutants Java c'est faire des manipulations de chaines avec String et + mais jamais StringBuffer
[^] # Re: ...
Posté par Sachiel . Évalué à 3.
Donc les débutant ne cherchent peut-être pas à savoir comment ça marche derrière... Mais a priori ce ne sont pas les seuls...
[^] # Re: ...
Posté par claudex . Évalué à 3.
C'est depuis la 1.5 si on en croit http://java.sun.com/javase/6/docs/api/java/lang/StringBuilde(...) , comme beaucoup de développement se fait sur des jvm 1.4 et que StringBuilder est limité aux monothread, il est tout à fait possible et probable que Gniarf ne puisse utiliser que StringBuffer.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ...
Posté par Sachiel . Évalué à 2.
Pour ce qui est mono-thread, on va dire que les cas d'utilisation d'une String par plusieurs Thread restent marginaux....
[^] # Re: ...
Posté par wismerhill . Évalué à 2.
Oui, mais seulement dans une même expression, et encore, s'il n'y a pas de parenthèses dans le chemin.
Un exemple typique de chose à ne pas faire c'est de la concaténation dans une boucle à coup de +=, par exemple
nb="";
for(int i=1;i<=10;i++){
nb+=" "+i;
}
Ça te crée autant de StringBuilder (si tu as la chance de pouvoir travailler avec java 1.5, sinon c'est StringBuffer) que de passage dans la boucle.
Et je l'ai déjà vu, parmis d'autres horreurs encore pire, et les gens se demandaient pourquoi leur bouzin était lent...
[^] # Re: ...
Posté par ckyl . Évalué à 2.
Oui c'est pas optimisé, oui c'est un goret qui a fait ca. Mais dans la vie réelle, si tu en arrives à ce que ce soit un problème de performance; alors tu as vraiment de la chance d'avoir une vie aussi simple. Par ce que tes problèmes ils se règlent en 1h de boulot. Sauf coder un hello world c'est pas ca qui fait la différence en général...
[^] # Re: ...
Posté par wismerhill . Évalué à 2.
Et c'est difficile de comprendre le code de quelqu'un qui ne comprend pas ce qu'il fait...
[^] # Re: ...
Posté par collinm (site web personnel) . Évalué à 3.
tu sais tu es pas le seul au monde avec de tel système....
www.solutions-norenda.com
[^] # Re: ...
Posté par windu.2b . Évalué à 7.
Si ça n'avait pas été conjugué avec les pieds, je n'aurais pas les yeux qui saignent...
[^] # Re: ...
Posté par ZankFrappa . Évalué à 5.
Moi j'aime bien.
[^] # Re: ...
Posté par Gabin . Évalué à 2.
Où ça en est?
Mais je ne l'utiliserais pas en production (!sic).
Quelles applis actuellement tirent parti dans sa phase de developpement?
Bref, vous avez des références, des bons bouquins à conseiller? Une communauté active?
merci
ps: Parcontre, je ne vois pas le lien direct avec Mono, si ce reprendre le paradigme C#.
[^] # Re: ...
Posté par fredix . Évalué à 2.
[^] # Re: ...
Posté par Gniarf . Évalué à 5.
* pourquoi Vala serait mieux que du C qui n'irait plus
* pourquoi Python, Ruby, C++ tout ça ne seraient pas adaptés à GNOME
comment Vala répond à ces affirmations ? à chacun de voir
par exemple, pour ma pomme,
* Vala ne répond pas aux vrais problèmes que C me pose
* Vala cause à GNOME à travers des fichiers d'interfaces (binding), technique qui précède largement Vala et GNOME.
ces fichiers peuvent être générés automagiquement. au pire, soyons fous, ces autres langages pourraient récupérer ces mêmes fichiers (qui feraient partie de la distribution standard de GNOME) pour leurs propres bindings.
voila là l'un des TRES rares apports de Vala à la scène du développement sous Linux : pour que Vala soit viable, il faut un accès aux fonctionnalités de GNOME, c'est à dire des bindings corrects, présents dès l'écriture de GNOME et pas rajoutés à la va-vite des années après. pratiquement comme de la documentation pour développeurs extérieurs au projet GNOME
et ça c'est juste une conséquence de son coté "le langage officiel du moment de GNOME pour coder pour GNOME", pas du tout de ses caractéristiques techniques, bonnes ou mauvaises, innovatrices ou obsolètes^Wclassiques et éprouvées
(maintenant, si j'étais pute, je parlerais de CORBA et autres Bonobo ...)
[^] # Re: ...
Posté par houra . Évalué à 2.
2 questions :
Vala ne répond pas aux vrais problèmes que C me pose
forcément: la question est :
- Connaissant une liste de projets développés en Vala , quels problèmes le C te pose que ne règle pas Vala ?
( http://live.gnome.org/Vala#Projects_Developed_in_Vala )
- Est-ce un langage intéressant si on veut développer une application système de type " gestionnaire de matériels " incluant des références de matériel dans une base NoSQL , accessible via l'utilisateur et capable d'aller chercher le mdp root pour les demandes de modification , et, capable d'aller chercher des nouveautés de matériel dans une base distante via web , sous 3 types de systèmes d'exploitation distincts ? ( BSD , Linux et .... Haiku ? ) :)
( il va de soi que tu as le droit de ne pas répondre pour Haiku ) .
Sedullus dux et princeps Lemovicum occiditur
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.