L'accessibilité n'est pas non plus oubliée avec l'intégration de KTTS, permettant de faire du "text to speech" (lecture audio de texte).
Pour ceux qui ne le sauraient pas, KDE est un environnement de bureau libre pour Linux/BSD qui se veut complet, efficace et multi plate-formes.
NdM: Merci également à gnumdk pour cette dépêche. Des packages sont déjà disponibles pour Gentoo, Arch Linux, SuSE RedHat... sinon il vous reste toujours l'option konstruct.
KDE 3.4 ne sera finalement pas le dernière version de KDE 3.x, le temps pour les développeurs de kdelibs de porter la base sous Qt4, une version de KDE 3.5 devrait sortir.
Bref pas mal de nouveautés, l'équipe devrait a priori commencer à travailler sur KDE 4 et ces nombreuses nouveautés tel que klink (framework permettant de faire des liens entre données, présenté au FOSDEM), kdemm (un "frontend" pour différent framework multimédia), sûrement l'abandon des autotools pour un autre système... D'ici là, il reste de nombreuses questions, comme le choix d'un nouveau framework multimédia, l'intégration de DBUS...
Aller plus loin
- L'annonce (1 clic)
- Les packages (2 clics)
- Le changelog (1 clic)
- Copies d'écran (1 clic)
- « KDE 3.4 RC1 » sur DLFP (3 clics)
# Autre chose prévue
Posté par Pinaraf . Évalué à 8.
C'est intéressant dans le sens où ça sera la plus grosse migration jamais faite de CVS vers subversion !
Maintenant, qu'est-ce-que ça va apporter ? Plus de fonctionnalités ? Plus de sécurité ? Plus de fonctionnalités pour les développeurs de KDE ?
[^] # Re: Autre chose prévue
Posté par Simon Depiets . Évalué à 3.
[^] # svn vs cvs
Posté par riri le breton (site web personnel) . Évalué à 9.
Du point de vue de l'utilisateur, svn n'apporte pas grand chose par rapport à cvs, mais du point de vue du contributeur, le 'préposé au remplacement' est bien plus agréable, car les commandes sont plus apparentées à celles des shells Unix.
Sinon, question stabilité et performance, je ne sais pas, le projet est de petite taille, et nous n'avons pas assez de recul pour donner un avis pertinent.
[^] # Re: svn vs cvs
Posté par galactikboulay . Évalué à 9.
Subversion fonctionne aussi avec WebDAV, ce qui est très pratique pour gérer ses "repository".
Mes 2 cents.
[^] # Re: svn vs cvs
Posté par Croweye . Évalué à 2.
http://www.edgewall.com/trac/(...)
quoique aucune idée comment il se positionne par rapport a webdav
[^] # Re: svn vs cvs
Posté par Pierre Habouzit . Évalué à 4.
bref, trac C'EST subversion .... (enfin, tout un environnement de dev au dessus de subversion pour etre précis)
[^] # Re: svn vs cvs
Posté par fabb . Évalué à 10.
D'un point de vu utilisateur, subversion apporte beaucoup.
- Tout est utf8
- support des répertoires
- meta-donné arbitraire
- support de lien symboliques
- copie à coût 0
- meilleur suivi des changelog même dans le cas de branchement
- renommage des fichiers/répertoires et déplacement des fichiers/répertoires les doigts dans le nez
- atomicité des transactions
- une transaction n'est pas une petite modif dans un coin, c'est tout changement d'arborescence. Par exemple une transaction peut être le passage de Linux 2.2.0 à Linux 2.6.11. Ça reste une seule modification et atomique.
- spécification de l'outil diff à utiliser. Ainsi, les modifications de données binaires sont supportés (le dépôt empile les diffs et pas les objets binaires complet)
- etc
svn apporte beaucoup par rapport à cvs pour l'utilisateur final.
> le projet est de petite taille
le src.rpm de cvs : 2 362 ko
le src.rpm de svn : 7 978 ko
[^] # Re: svn vs cvs
Posté par CoinKoin . Évalué à 9.
>le src.rpm de cvs : 2 362 ko
>le src.rpm de svn : 7 978 ko
Je pense que lorsqu'il écrivait "le projet est de petite taille", il pensait au projet qu'il menait, pas aux projets cvs/svn.
[^] # Re: svn vs cvs
Posté par Philippe F (site web personnel) . Évalué à 6.
Les astucieux auront tout de suite note que cela signifie que tous les fichiers sont en double en local: version modifiee et version non modifiee. Ca prend donc deux fois plus de place, mais les fichirers texte ne prennent pas beaucoup de place.
A cote de ca, c'est _super_ pratique de pouvoir annuler ses changements rapidement, ou bien de regarder ce qu'on a change en une seconde.
[^] # Re: svn vs cvs
Posté par spart . Évalué à 3.
> faire un diff de facon instantanee, sans avoir une connexion avec le
> serveur.
à ce propos, je me suis toujours demandé si avec CVS, les diffs étaient confidentiels...
Il me semble que ça se fait sur le serveur, qui t'envoie le diff après coup non?
désagréable idée...
[^] # Re: Autre chose prévue
Posté par finss (site web personnel) . Évalué à -4.
oupssss une porte --------------> []
\_o<
[^] # Re: Autre chose prévue
Posté par Dabowl_94 . Évalué à -2.
En plus pour pouvoir troller il faut quand même se taper 3 heures de compilation et quelques heures de test, ou alors attendre l'intégration du nouveau kde dans experimental/unstable au risque de se taper un upgrade foireux avec des dépendances toutes cassées :-), et ceci n'est pas un troll poilu.
bon ok j'arrive ---> []
dabowl_75
[^] # Re: Autre chose prévue
Posté par Dabowl_94 . Évalué à 2.
dabowl_75
[^] # Re: Autre chose prévue
Posté par udok . Évalué à 4.
http://developer.kde.org/development-versions/kde-3.5-features.html(...)
http://developer.kde.org/development-versions/kde-4.0-features.html(...)
vivement les futures versions ! :D
[^] # Re: Autre chose prévue
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
# JuK
Posté par gnumdk (site web personnel) . Évalué à 5.
Le systray à lui aussi été amélioré en permettant de cacher certaines applications à la windows XP. Les devels de kde esperent bien pouvoir faire ca plus proprement avec D-Bus pour kde4.
[^] # Re: JuK
Posté par CoinKoin . Évalué à 3.
Qu'est ce que c'est, ça? Et à quoi est-ce que ça sert, de cacher des applications?
[^] # Re: JuK
Posté par _ . Évalué à 5.
J'y ai cependant trouvé une application : la solution la plus simple (quand on est sous kde) pour prendre en compte les touches volume du clavier est d'activer son clavier dans le centre de contrôle de kde. Cela rajoute deux icones dans le tray : le drapeau de la langue du clavier et l'icone de kmix, qui se lance dès qu'on appuie sur la touche. Je n'ai a priori pas besoin de voir ces deux icones, et elles prennent de la place, mais j'ai besoin des services qui y sont associés.
On pourait se dire que ces programmes devraient inclure une option "ne pas afficher l'icone", mais cela va peut-être à l'encontre de la philosophie du bureau destiné à monsieur tout le monde en lui rappelant que ces programmes tournent en tâche de fond
[^] # Re: JuK
Posté par Anonyme . Évalué à 4.
Et sinon, en ce qui concerne kmix, pourquoi ne pas passer par aumix pour le réglage du son via le clavier ? Du coup, kmix n'aurait plus besoin d'être lancé, donc plus d'icône non plus :-p
[^] # Re: JuK
Posté par Obsidian . Évalué à 2.
Cela signifie aussi que la philosophie de la plupart des nouveaux utilisateurs est « Je me mettrai à Linux le jour où il ressemblera à Windows ».
Pas très encourageant, à dire vrai ...
[^] # Re: JuK
Posté par Benjamin François (site web personnel) . Évalué à -1.
Pas très encourageant, à dire vrai ...
Il ne faut pas se leurrer, c'est cette ressemblance qui a toujours attiré énormément de monde vers KDE.
[^] # Re: JuK
Posté par Amand Tihon (site web personnel) . Évalué à 4.
Jusqu'il y a environ deux ans, époque à laquelle j'ai redonné sa chance à cet environnement, qui m'a alors séduit.
Évidemment, il avait évolué (et moi aussi probablement).
Maintenant, je l'utilise parce qu'il me plaît, et je ne peux pas trop parler de ressemblances avec Windows puisque je n'ai plus réellement utilisé ce dernier depuis ses version 98 et NT4.
[^] # Re: JuK
Posté par Spyhawk . Évalué à 10.
KDE comme dit sur le site officiel "fait son propre chemin".
KDE ne ressemble à rien d'existant, ou il ressemble à tout ce qui existe (cochez ce qui vous convient, il n'y a pas de bonne/mauvaise réponse).
L'interface KDE c'est celle windows, MacOS, ou d'autre encore (pas d'exemples, ma culture générale en terme de GUI est assez limitée, et je ne sens pas le besoin de l'appronfondir).
KDE c'est KDE, point. S'il "pique" des idées par-ci par là sur des interfaces existantes et qui ont fait leur preuve, tant mieux.
KDE est modulable à souhait, configurable à 150% et même plus...
KDE, c'est bon.
[^] # Re: JuK
Posté par Benjamin François (site web personnel) . Évalué à 3.
Je ne dis pas le contraire. Aux origines du projet, on le vendait comme une interface graphique «comme Windows» pour Linux/*BSD/etc.
La personne à qui je répondais avait l'air de dire que cette volonté de retrouver une interface qui ressemble à Windows était propre aux «nouveaux utilisateurs» et qu'il ne trouvait pas ça «très encourageant». J'ai l'impression qu'il ne se rend pas bien compte de quand elle date, cette volonté.
[^] # Re: JuK
Posté par Pierre Habouzit . Évalué à 2.
pour le drapeau, ca fait partie des options
kmix aussi peut, mais ca le fait planter... (enfin, ca le faisait avec kde 3.3.x, je n'ai pas essayé avec 3.4)
[^] # Re: JuK
Posté par un_brice (site web personnel) . Évalué à 2.
# Sous Debian...
Posté par Sebastien . Évalué à 5.
Et sous Debian il ne faut pas oublier les packages disponibles sur alioth :
deb http://pkg-kde.alioth.debian.org/kde-3.4.0/(...) ./
Je me suis laisse dire que ces paquets etaient maintenus par des devs de KDE donc bon, ca devrait etre relativement serieux (pas teste, pas taper).
[^] # Re: Sous Debian...
Posté par Amand Tihon (site web personnel) . Évalué à 1.
[^] # Re: Sous Debian...
Posté par Pierre Habouzit . Évalué à 2.
btw, j'ai fait un post sur debian-qt-kde@lists.debian.org à ce sujet, ca doit se trouver facilement dans les archives.
--
Proud Debian KDE Packager
[^] # Re: Sous Debian...
Posté par udok . Évalué à 5.
c'est l'équivalent d'experimental
j'ai pas trop suivit pourquoi mais apparemment les mainteneurs kde ne veulent pas le mettre dans experimental mais ce dépot est à considérer comme tel (donc pas forcément parfait mais supporté et correct)
y-a déjà eu des commentaires dessus et il semble fonctionner correctement (à part arts qui peut poser pb avec les .ogg)
les i18n seront bientot sur alioth (ils sont sur people.debian.org pour le moment) mais ont déjà un pb de dépendance (au niveau des versions)
et pour ceux qui auraient pas compris : ce sont les mainteneurs officiels qui s'en occupent
petite remarque : les packages ont été entièrement refaits avec cdbs au lieu et place de debhelper (les mainteneurs font en sorte que le fichier de conf cdbs puissent fonctionner pour n'importe quel appli kde qui n'est pas encore packager pour faciliter l'ajout de nouveau programme kde dans debian)
sinon je viens d'installer ces paquets et ils marchent très bien
l'installation se passe sans soucis
- il manque juste kdm (il faut installer la version 3.3.2-1b disponible sur alioth, la version 3.4 à encore besoin de travail apparemment)
- je confirme le pb de dépendance avec kde-i18n :
il suffit de forcer l'install du paquet. Pour ça perso j'ai téléchargé le paquet à la main et je l'ai installé avec la commande :
dpkg --force-depends -i kde-i18n-fr*.deb
puis éditer le fichier /var/lib/dpkg/status en changeant, dans la section depends, la version pour kdelibs4 en 4:3.4.0-0pre1 pour éviter que apt-get ne cherche à désinstaller kde-i18n-fr à chaque fois que vous cherchez à mettre à jour votre système (entre autre)
[^] # Re: Sous Debian...
Posté par sanao . Évalué à 2.
Sinon, pourquoi il y a un problème avec les dépendances pour le paquet de la localisation?
[^] # Re: Sous Debian...
Posté par udok . Évalué à 1.
il a dit qu'il règlerait ça bientot, mais vu que la bande passante n'est pas illimité, je peuse qu'il va falloir faire avec pendant quelques temps
[^] # Re: Sous Debian...
Posté par sanao . Évalué à 1.
Lorsque je veux mettre un fichier dans la corbeille il me dit que le kioslave trash n'existe pas. Ce bug est connu ou pas?
D'ailleurs il y a une page où sont recensés les bugs?
[^] # Re: Sous Debian...
Posté par udok . Évalué à 2.
http://lists.debian.org/debian-qt-kde/2005/03/index.html(...)
et pour ton bug, j'ai pas l'impression que je l'ai (j'ai fait qu'un seul test, en général je supprime complètement sans passé par la case "corbeille" en utilisant shift+suppr)
[^] # Re: Sous Debian...
Posté par sanao . Évalué à 3.
Après recherche, je me suis aperçu qu'il me manquait le package kdebase-kio-plugins. Après installation, trash est maintenant présent.
Je vais jeter un coup d'oeil à la mailing list. Merci.
[^] # Re: Sous Debian...
Posté par gnumdk (site web personnel) . Évalué à 0.
>trash n'existe pas.
Ce n'est pas un bug, c'est ton installation qui est foireuse.
[^] # Re: Sous Debian...
Posté par Pierre Habouzit . Évalué à 3.
soit dit en passant, pour toute install kde qui se respecte, c'est mieux encore de faire :
apt-get install kde-core
qui t'installe kdelibs, kdebase, arts, et fontconfig et ca te permet en général d'avoir tout ce qu'il faut.
en tout cas, moi j'ai le kio_trash installé :
[madcoder hades] dpkg -L kdebase-kio-plugins|grep kio_trash
/usr/lib/kde3/kio_trash.la
/usr/lib/kde3/kio_trash.so
[^] # Re: Sous Debian...
Posté par Pierre Habouzit . Évalué à 5.
on ne veut pas uploader dans experimental parce que tous les paquets ne sont pas prets à 100%. au niveau utilisateur ca se passe bien, mais au niveau QA debian, on a encore un peu de travail pour que ca soit vraiment parfait.
De plus, il reste les problèmes avec kdm qu'on a pas encore eu le temps de gérer (la transition depuis kdm de 3,3,x est un peu douloureuse au niveau de la conf).
Par contre, je pense que 3.4. ne touchera pas la sid avant un moment, vu que sid est l'entrée pour testing, et que en testing ca sera kde 3.3.2, et qu'il reste du boulot à cause des failles de sécu récentes de kde (IDN et attaque sur dcop).
donc il y aura sans doute des uploads dans expérimental, au moins pour trigger les processing de NEW (il y a un tas de nouveaux paquets pour kde 3.4 : kttsd, akregator qui entre dans kdepim, et j'en passe)
--
Proud Debian KDE Packager
[^] # Re: Sous Debian...
Posté par udok . Évalué à 2.
merci pour tout ce bon travail, les paquets marchent vraiment bien
d'ailleurs l'idée de tout passer en cdbs est vraiment bien venu (reste kdepim si j'ai bien suivi)
sinon pour kdm 3.4 j'avais quand même tenter le coup parce que ça me dérangeait pas de refaire la conf mais il m'a mis qu'il me manquait des widgets, tu saurais pas d'où ça vient ? (j'ai pas trouvé sur la ML)
[^] # Re: Sous Debian...
Posté par Pierre Habouzit . Évalué à 1.
en fait kdepim etait deja en cdbs, mais il est maintenu par un type un peu en dehors de la team pour le moment.
pour kdm 3.4 c'est corrigé
[^] # Re: Sous Debian...
Posté par Victor . Évalué à 1.
[^] # Re: Sous Debian...
Posté par Pierre Habouzit . Évalué à 2.
ce qu iveut dire comme c'est apres le dash final, que c'est le *paquet* qui est en version pre1, pas son contenu, sinon ca serait 3.4.0-pre1-0 (enfin, pas tout à fait, mais c'est l'idée)
--
Proud Debian KDE Packager
[^] # Re: Sous Debian...
Posté par Victor . Évalué à 3.
# arf probleme
Posté par Tractica . Évalué à 1.
je suis en train d'essayer de télécharger KDE 3.4 pour ma suse 9.2 mais lorsque je mets cette adresse ftp://ftp.lip6.fr/pub/X11/kde/stable/3.4/SuSE/ix86/9.2/(...) ds la rubrique "emplacement" pour la mise a jour en ligne, j'ai une erreur qui s'affiche "échec de l'obtention des informations sur les patches.error
Couldn't cd to i386"
alors que quand je tape cette meme adresse dans Konqueror, j'ai bien une liste de tous les RPM
comment faire ?
[^] # Re: arf probleme
Posté par Gérald Toussaint . Évalué à 3.
Bon, je ne suis plus sous SuSE, mais je donne ces liens.
http://packman.links2linux.org/(...) pakages non officiels
ftp://ftp.belnet.be/mirror/ftp.suse.com/suse/i386/9.2/(...)
ftp://ftp.belnet.be/mirror/ftp.suse.com/(...)
Pour ajouter packman et les maj KDE aller dans Yast puis
choisir "Changer le support d'installation
Ajouter ---> ftp
*pour KDE*
-Nom du serveur :
ftp.belnet.be
-Répertoire sur le serveur :
pub/linux/suse/suse/i386/supplementary/KDE/update_for_9.2/yast-source
*Pour Packman*
-Nom du serveur :
ftp.gwdg.de
-Répertoire sur le serveur :
pub/linux/misc/packman/suse/9.2
*Pour supplementary applications and tools*
-Nom du serveur :
ftp.belnet.be
-Répertoire sur le serveur :
pub/linux/suse/suse/i386/supplementary/misc/update_for_9.2/yast-source
Il faut réactualiser ces sources de temps à autre
Suser 9.2
ftp://ftp.gwdg.de/pub/linux/misc/suser-gbv/rpms/SuSE_9.2(...)
ftp://ftp.gwdg.de/pub/linux/misc/suser-jmorris/suse92(...)
ftp://ftp.gwdg.de/pub/linux/misc/suser-oc2pus/suse92(...)
ftp://ftp.gwdg.de/pub/linux/misc/suser-scorot/suse92/i686/RPMS(...)
ftp://ftp.gwdg.de/pub/linux/misc/suser-tcousin/suse92(...)
ftp://ftp.gwdg.de/pub/linux/misc/apt4rpm/9.2(...)
ftp://ftp.gwdg.de/pub/linux/misc/funktronics/SuSE-9.2(...)
Forums Français
Alionet, forum d'entraide SuSE
http://www.alionet.org/(...)
Forum Linux Suisse -
http://www.swisslinux.org/forums/(...)
Forums Anglais
http://www.linuxforum.com/forums/index.php?showforum=23(...)
http://www.linuxiso.org/forums/viewforum.php?forum=36(...)
# Et chez Mandrake ils font quoi ?
Posté par Kalimero . Évalué à -1.
Pom, pom, pom ----------> []
[^] # Re: Et chez Mandrake ils font quoi ?
Posté par Kalimero . Évalué à -1.
[^] # Re: Et chez Mandrake ils font quoi ?
Posté par Bruce Le Nain (site web personnel) . Évalué à 2.
¿¿¿gni???
Concernant l'intégration de KDE 3.4, les vérifications de dépendance ne se font pas en deux secondes. KDE c'est pas ''un petit paquet''...
Sinon, comme pour chaque distribution, tu as des paquets non officiels :
http://rpm.nyvalls.se/(...)
[^] # Re: Et chez Mandrake ils font quoi ?
Posté par gnumdk (site web personnel) . Évalué à 3.
[^] # Re: Et chez Mandrake ils font quoi ?
Posté par Kalimero . Évalué à 0.
Bon, visiblement tu n'as pas compris que mon propos était ironique. Mais le fait est qu'il fut une époque glorieuse (du temps de la 9.0/9.1) où Mandrake proposait des paquets du dernier KDE sur le serveur officiel de KDE. Ce temps est semble-t-il révolu depuis un moment et on peut le regrêter. Maintenant c'est réservé aux membres du Club ...
Tu me diras : "Mandrake est une distribution commerciale". Ok, mais Suse aussi et leurs paquets officiels sont toujours dans les premiers sur kde.org ! Voilà, c'est là où je voulais en venir ...
Pour le reste on est d'accord, KDE c'est pas simple à intéger et à tester et en ce moment les petits gars de Mandrake sont bien pris par la future 10.2. Il y avait volontairement un peu de provoc dans mon post et visiblement ça a bien marché ! ;-)
Pour ce qui est des paquets KDE non officiels de Thac ... hum ... joker !
[^] # Re: Et chez Mandrake ils font quoi ?
Posté par fabb . Évalué à 0.
C'est vraiment trop injuste. Mon pauvre petit Kalimero.
M'enfin, t'as pas tord.
J'ai une idée (histoire que tu ne sois pas le seul à être moinsé) :
- laisses tomber Mandrake
[^] # Re: Et chez Mandrake ils font quoi ?
Posté par zeb . Évalué à 7.
D'autre part tes insinuations sur le club sont completement gratuites. Tu ne sais absolument pas quand et comment ces paquets seront distribues. On a eu exactement les memes remarques a propos de la x86_64. Cette fois, des isos vont etre publics (en sus des miroirs FTPs deja disponibles, ainsi que les outils permettant de fabriquer ces isos). C'est facile de taper, mais au moins il faut etre sur de ce que l'on affirme pour eviter de passer pour un aigri.
Par ailleurs, pour ce qui est du club, j'en fais partie en effet. Mais tu sais quoi ? Sans jamais avoir debourse un seul sou. Il suffit de maintenir quelques paquets dans les contributions, ou bien participer a l'ecriture des docs, ou bien moderer le club, etc... Le commercial ne signifie pas forcement de l'argent.
[^] # Re: Et chez Mandrake ils font quoi ?
Posté par fabb . Évalué à 1.
Mauvaise raison. Il y a plus de traduction dans KDE 3.4 que dans KDE 3.3.
Le src.rpm de kde-i18n de KDE 3.3 pèse 176 Mo celui de KDE 3.4 243 Mo.
Les traducteurs ne sont pas mainteneurs. Ils bossent sur la version upstream et font en sorte que les nouvelles soient les plus complètes possibles.
Enfin, à ma connaissance Mandrake ne s'occupe pas de l'internationalisation de KDE. Pour KDE ils ne font aucun travail spécifique sur la traduction (ou alors c'est très très limité).
> Le probleme s'etait egalement pose avec KDE 3.3.
Mauvaise réponse.
Globalement Mandrake fait le choix de baser ses distributions sur des solutions éprouvées (ça n'a pas toujours été le cas). Je ne dis pas que c'est un mauvais choix mais c'est un choix de Mandrake et qu'il faut assumer.
Fedora fait le choix "d'aller de l'avant" d'être là où les choses se passent (en bien et en mal).
Ça se voit sur les plannings. Je dirais presque que Mandrake fait en sorte que les nouvelles versions de KDE/Gnome sortent trop tard pour leur planning. Fedora repousse le planning si nécessaire. La démarche est complètement différente.
Puis je ne serais pas étonné que Mandrake réserve KDE 3.4 aux "clubbers".
> d'ailleurs KD 3.4 est parait-il fortement buggue dans la Fedora Core 4 rc
T'es charmant. Déjà il n'y a pas de rc de FC4. Il y a la test 1 (la version finale est pour début juin). C'est la toute première beta et donc forcément il y a des bugs et même beaucoup (pas forcément liés à KDE).
FC4T1 a kde 3.4.0-rc1 et pas la version finale de kde. La version finale de KDE 3.4.0 sera dans Rawhide aujourd'hui ou demain.
Les paquets KDE 3.4 pour Fedora dispos sur kde.org sont fait par un employé Red Hat. C'est une iniative personnelle.
Mandrake, son épique, ne veut pas ou ne peut pas le faire. Faut assumer.
> D'autre part tes insinuations sur le club sont completement gratuites.
Ce n'est pas gratuit. Mandrake a décidé pour KDE 3.3 de le fournir en exclusivité pour les membres payants (boîte ou club). C'est le choix de Mandrake donc Mandrake est critiquable. Partant de ça, Mandrake a peut-être de bonnes raisons et c'est sur ces raisons que tu pourrais éclairer les gens au lieu de dire n'importe quoi.
> On a eu exactement les memes remarques a propos de la x86_64. Cette fois, des isos vont etre publics
Donc tu démontres que les critiques/remarques/mécontentements étaient justifiées.
Red Hat fait le choix de ne pas fournir RHEL en binaire gratuitement. Red Hat se fait critiquer et donc il faut justifier ce choix avec de bons arguements. Ben pour RHEL comme pour x86_64 de Mandrake ou KDE 3.3 uniquement pour les "clubbers" c'est pour des raisons de business/pognon et pas des raisons de i18n ou je ne sais quoi d'autre.
Je ne dis pas que le pognon c'est mal(tm). Mais seulement qu'il faut assumer les choix qui sont faits. Et les assumer dans les deux sens. RHEL payant permet d'avoir Fedora gratuit et Mandrakeclub, etc permet d'avoir MandrakeLinux gratuit.
C'est dingue, je n'utilise pas KDE mais là je suis obligé de défendre KDE.
[^] # Re: Et chez Mandrake ils font quoi ?
Posté par zeb . Évalué à 5.
C'est vrai que la taille des fichiers i18n est un gage d'asurance qualite. On n'a plus besoin de tester: hop, il y a 100Mo de plus, ca veut dire qu'on peut les integrer 15 jours avant la release.
> Donc tu démontres que les critiques/remarques/mécontentements étaient justifiées. [...] Red Hat se fait critiquer[...]
Ca ne demontre absolument rien. Je n'ai d'ailleurs jamais critique RHEL, c'est libre. Ce que tu ne comprends pas c'est que je ne cherche pas a rentrer dans une guerre de distro. Comme a ton habitude, tu cherches toujours a opposer Mdk et RH, mais moi pas, ca ne m'interesse pas. Chacun est libre d'utiliser ce qu'il veut. Mon exemple pris avec KDE dans la Fedora n'etait pas une pique contre Fedora, mais pour souligner qu'integrer KDE 3.4 etait risque 15 jours avant la release.
>Et les assumer dans les deux sens. RHEL payant permet d'avoir Fedora gratuit et Mandrakeclub, etc permet d'avoir MandrakeLinux gratuit.
J'ai jamais dit le contraire. Ce qui m'importe, c'est le respect du libre. Or Mandrake en a toujours respecte les principes. Ils ont toujours respecte les regles du libre, et je n'ai pas eu de probleme a faire accepter mes paquets en tant que contributeur. Les sources sont toujours accessibles, les binaires sont dispos parfois sous forme d'isos, toujours sous forme d'une branche FTP, avec les outils permettant de creer les CDs. Je ne pense pas qu'on puissse faire beaucoup mieux, surtout de la part d'une boite qui sort a peine de la cessation de paiement.
Peut-etre qu'un jour tu comprendras que des gens aiment utiliser telle ou telle distro, ou plusieurs, sans avoir sur le dos des personnes pour les critiquer, les juger, troller...
[^] # Re: Et chez Mandrake ils font quoi ?
Posté par fabb . Évalué à -1.
Tu parle de SuSE et Fedora et après tu fais la leçon.
T'as le moral toi.
> Ce qui m'importe, c'est le respect du libre. Or Mandrake en a toujours respecte les principes. Ils ont toujours respecte les regles du libre, et je n'ai pas eu de probleme a faire accepter mes paquets en tant que contributeur.
C'est pas le sujet du thread. Le sujet est une personne qui se plaint que KDE 3.4 n'est pas dispo pour Mandrake (realese actuel et la prochaine release) et qu'il sent que KDE 3.4 sera uniquement dispo pour les clubbers.
> Peut-etre qu'un jour tu comprendras que des gens aiment utiliser telle ou telle distro, ou plusieurs, sans avoir sur le dos des personnes pour les critiquer, les juger, troller...
Peut-être qu'un jour tu répondras aux interrogations légitimes des gens au-lieu de faire systématiquement de la pub à 2 balles.
Ton post n'a absolument rien apporté à ce thread.
[^] # Re: Et chez Mandrake ils font quoi ?
Posté par Barnabé . Évalué à -1.
Visiblement, tout le monde ne partage pas ton avis.
[^] # Re: Et chez Mandrake ils font quoi ?
Posté par fabb . Évalué à 0.
T'as raison, évites de parler du contenu par rapport au problème initial.
[^] # Incroyable...
Posté par Anonyme . Évalué à -7.
Alors soit il y a vraiment un foutu paquet d'imbéciles qui ont le pouvoir de noter et qui ne s'en privent pas (auquel cas, il serait bon qu'il s'interroge sur le sens des mots « pertinent » et « inutile »), soit il y a sur ce site un fort lobbying de soutien à Mandrakelinux.
Dans les 2 cas, ce serait extrêmement puant, et particulièrement bas.
Tant que j'y suis, vous pouvez doublement inutilisanter mon commentaire, parce qu'après avoir acheté 5 PowerPack Mandrakelinux, 1 Mandrakelinux AMD64, et 3 Mandrakelinux Discovery, j'ai décidé de ne plus acheter de packs Mandrake pour le moment (tant que je ne verrais pas un changement significatif dans ce qui ne me convient pas du moins) et de ne pas renouveller mon abonnement au MandrakeClub, et très certainement de ne plus participer à l'avenir au bug-reporting auquel je me livrais jusqu'à présent sur ma MandrakeCooker.
[^] # Re: Incroyable...
Posté par zeb . Évalué à 2.
Tu es libre de faire ce que tu veux. C'est ca Linux, la liberte. On dirait qu'on vous a forces a utiliser Mandrake et que maintenant, tels des "freedom fighters", vous devez partir en croisade contre cette distro.
[^] # Re: Incroyable...
Posté par Anonyme . Évalué à 8.
Cela dit, depuis que je l'ai découverte, pas mal de choses ont changé. Peut-être que ces changements sont du fait des ennuis financiers rencontrés, toujours est-il que désormais certaines pratiques de Mandrakesoft ne me conviennent plus vraiment, par exemple :
- MandrakeMove version download qui est bridée
- Mandrakelinux version download qui n'est disponible qu'1 ou 2 mois après la sortie pour le MandrakeClub
- Mandrakelinux AMD64 qui n'était pas disponible sous forme d'iso à moins de payer le prix fort (199 ¤ il y a quelques mois à peine)
De même, le support matériel et certains bogues laissent vraiment à désirer depuis quelque temps :
- Sound Blaster Live! très mal supportée (pas reconnue par alsa, puis problème de reconnaissance par le kernel, puis reconnue à nouveau mais pas de son avec les jeux et flash, etc.)
- support de l'ACPI désastreux
- problème de support de nombreux lecteurs de DVD, dont les Pioneer (qui n'existe pas avec d'autres distribs)
- Drakconf qui plante sur le splashscreen (et une mandrake sans drakconf, c'est quoi pour un débutant ?)
Sinon, dans l'ensemble, les choix Mandrake sont aussi assez incohérents :
- Support de KDE comme environnement par défaut mais applications Gnome ou GTK (evolution, totem, etc.) définies comme applications par défaut.
- Outils Drak* qui pourraient au moins bénéficier d'une interface en QT
Bon, je m'arrête là, mais je pense que tu auras saisi en gros le pourquoi de mes critiques. Le vrai problème, c'est que le fait de critiquer Mandrakelinux t'expose, même en apportant des arguments, t'expose à un inutilisantage quasi-systématique, et à des commentaires débiles du genre « chez moi ça marche donc t'es qu'un gros naze », voire à d'autres encore pire « où sont tes bug reports » (génial, surtout quand tu as payé 199 euros le pack AMD64 pour pas être emmerdé justement)
Le vrai problème, ce n'est pas Mandrakelinux, mais la communauté d'irréductibles imbéciles présents sur ce site et qui font un lobbying très appuyé en faveur de cette distribution.
Il n'est pas question d'une croisade contre cette distro, mais de faire en sorte que la critique soit équitable entre toutes les distributions, et que ces critiques remontent à Mandrakesoft. J'ai encore en mémoire les critiques acerbes envers SuSE et Red Hat, notamment lorsque Red Hat innovait sur pas mal de choses, et que ses choix étaient vivement critiqués ici-même par les utilisateurs Mandrake, pour qu'au final Mandrakelinux suive, toujours après, une fois que les choix techniques avaient été imposés et éprouvés.
Au final, on voit ce que ça a donné : SuSE a été la première distribution à sortir une version 64 bits, et est la seule à être certifiée LSB 2.0, Fedora FC3 et encore plus FC4 intègre déjà des nouvelles technologies qui sont pas encore présentes chez Mandrake, et qui le seront forcément à l'avenir.
Donc le coup des « freedom fighters » a bon dos, parce que j'ai plutôt l'impression que la mauvaise foi se fait dans l'autre sens.
[^] # Re: Incroyable...
Posté par Frederic Bourgeois (site web personnel) . Évalué à 4.
Oui, sauf qu'ici tes remarques sont constructives, ce qui n'est pas toujours le cas dans tes commentaires (par exemple faire un journal pour se plaindre de la Mandrake en version Cooker).
chez moi ça marche donc t'es qu'un gros naze
C'est stupide, mais autant que chez moi ça ne marche pas donc c'est de la
Merde, qui revient à faire des généralités avec sa machine.
support de l'ACPI désastreux.
Drakconf qui plante sur le splashscreen
chez moi ça marche ; -)
[^] # Re: Incroyable...
Posté par Anonyme . Évalué à 2.
Attention de ne pas confondre, si j'ai fait un journal, ce n'est pas parce que ma MandrakeCooker a eu un problème, mais parce que 3 versions différentes de Mandrakelinux, sur 3 machines différentes, ont connu le même genre de problème ( http://linuxfr.org/comments/547209.html#547209(...) ).
Il s'avère qu'après en avoir discuté sur la tribune et avoir googlisé, beaucoup d'utilisateurs Mandrakelinux ont rencontré ce genre de problème avec ext3fs, et que le ext3fs de Red Hat est fortement patché.
Je ne suis donc pas en mesure de savoir, à l'heure actuelle, si la faute incombe à Mandrakesoft ou à ext3fs, et c'est donc la raison pour laquelle je n'ai pas encore posté ce fameux journal que certains attendent encore, parce que contrairement à ce que certains ont l'air de penser, mon but n'est pas de critiquer Mandrakelinux aveuglément, bien au contraire.
Après tu conviendras que 3 crash de système de fichiers sur 3 machines différentes en moins de 1 an, il y a de quoi s'énerver, même si tu as des sauvegardes, parce que cela ne m'est jamais arrivé personnellement en presque 10 ans de NTFS ! :-)
[^] # Re: Incroyable...
Posté par fabb . Évalué à 4.
Non. Les src.rpm sont à dispositions, tu peux vérifier. Par contre Red Hat est le principale développeur/mainteneur de ext3 et lorsqu'il développe une nouvelle fonctionnalité elle est en premier testé largement sur Fedora (durant les phases beta) puis remonté en upstream.
[^] # Re: Incroyable...
Posté par Pierre Tramo (site web personnel) . Évalué à 3.
Mais qui te forçait à utiliser ext3? Quand un truc déconne, faut pas être très malin pour le s'acharner à le réutiliser. Il y a plein d'autres systêmes de fichiers sous linux. J'utilise xfs depuis des années, j'ai jamais eu le moindre problème. J'ai voulu retester ext3 y a pas longtemps, en un mois, j'ai eu 2x des données corrompues(sur debian et mandrake). Je ne commence pas à gueuler partout que ces distros suxent(ou alors, pas pour cette raison)
[^] # Re: Incroyable...
Posté par Anonyme . Évalué à 2.
Mandrake ? Je rappelle que ext3fs est le choix par défaut de Mandrakelinux, et que ce choix est conservé par la grande majorité, notamment par les nouveaux venus à Linux.
On est bien d'accord, mais comme je l'indique, les pannes se sont produites à quelques mois d'intervalle, et jusque là, rien ne laisser présager que le choix par Mandrake était *merdique*. Par contre, il est évident que pour moi, ext3fs c'est fini.
Là où j'ai gueulé sur Mandrake suite à ce crash de fs, c'est que les outils de récupération made-in-Mandrake font encore plus de dégâts que le crash lui même !
En tout cas, je note que visiblement le problème n'est pas spécifique à Mandrakelinux (puisque tu l'as connu aussi sous Debian), et que donc, il me faut vraiment définitivement abandonner ext3fs :-)
[^] # Re: Incroyable...
Posté par fabb . Évalué à 0.
Tu devrais réfléchir un peu.
Recherche google "ext3" and "corrupted" : 23 300
Recherche google "reiserfs" and "corrupted" : 21 000
Recherche google "xfs" and "corrupted" : 14 700
Sachant que ext3 est le plus utilisé et de loin, tu devrais y réfléchir un peu plus.
Pour info :
Recherche google "ntfs" and "corrupted" and not "linux" : 59 300
Il semble que tu n'as pas lu ma réponse à un de tes commentaires dans un journal.
http://linuxfr.org/comments/548899.html#548899(...)
[^] # Re: Incroyable...
Posté par gnumdk (site web personnel) . Évalué à 2.
Des que t'as une installation éléctrique qui fatigue, ext3 n'est pas un bon choix, sauf si tu veux te retrouver avec tes partoches dead de chez dead.
[^] # Re: Incroyable...
Posté par fabb . Évalué à 1.
Si ext3 c'est de la merde, il ne serait pas utilisé si massivement.
Un test ext3/reiserfs/xfs/jfs :
https://www.redhat.com/archives/fedora-list/2004-July/msg00418.html(...)
[1] Ce problème des 2 lignes perdus est "normal". Il est expliqué par Alan Cox plus loin.
[^] # Re: Incroyable...
Posté par Raphaël G. (site web personnel) . Évalué à 1.
Depuis j'utilise quotidiennement et j'ai eu un soucis très récementsur le / (pas de xfs_repair sur le / depuis des mois et 8 freeze du system ont eu raison de lui...)
Donc je recommande xfs MAIS il faut faire du xfs_repair (très chiant) régulièrement sinon on risque de perdre des données...
Cela est du au fsck.xfs qui est un int main {return 1}
Je vais conder un patch pourque le fsck.xfs marche au démarage et évite trop de démarage avec des partoche crashés
/!\ Je n'ai perdu aucune donnée dans mon /home et dans toutes mes autres partoches de données... Donc xfs on continue...
[^] # Re: Incroyable...
Posté par fabb . Évalué à 1.
Apparament la majorité des problèmes ext3 sont sous Mandrake.
J'invite les gens à fouiller les mailings et le bugzilla de Red Hat. Les problèmes ext3 sont rares (mais ils existent).
Je l'ai déjà dit ailleur, mais des problèmes avec ext3 ont déjà été rencontré alors qu'il ne sont pas liés à ext3 mais à des drivers qui foutent le bordel dans la mémoire du noyau. Mandrake ajoute beaucoup de driver et peut-être qu'à certaines époques celà a affecté ext3.
[^] # Re: Incroyable...
Posté par freeture . Évalué à 2.
Entièrement d'accord sur Drakconf &co, mais totem ou évolution par defaut, c'est pas dans la 10.2 en tout cas.
On peut aussi se plaindre du contraire, le journal annonçant KDE 3.4 parlait presque exclusivement du manque de cette version dans la futur mandrake...
Oui mais la LSB2 ...
Fedora est une sorte de RedHat en version Beta, donc c'est pas étonnant.
Mandrake à passer pas mal de temps à faire un KDE3.3 stable, et ils ont porté les choses les plus intéréssantes de 3.4 dans 3.3 (Kpdf..).
[^] # Re: Incroyable...
Posté par fabb . Évalué à 1.
Ce troll récurrent... Pénible.
Fedora n'est pas une beta. C'est le lieu où Red Hat et d'autres mijotent des évolutions techniques. C'est fait en phase beta de Fedora ou dans Rawhide. Si ça marche c'est activé en version finale si ça ne marche pas c'est désactivé. Ainsi pour FC2, selinux était présent mais désactivé car il y avait encore trop de problème et pour FC3 selinux est présent et activé.
Pourquoi ce n'est pas fait avec RHEL ?
Car RHEL n'est pas un bon cadre pour ça. Si on veut attirer des contributeurs il est de bon ton de le faire sur un produit gratuit et "communautaire". RHEL est basé sur Fedora mais n'a pas pour objectif de faire avancer le libre mais "uniquement" pour satisfaire ses clients.
De plus Fedora permet à Red Hat d'avoir des feedback des utilisateurs *avant* de proposer un produit. C'est ainsi (parmis plein d'autres choses) que les règles targeted pour SeLinux ont été faite pour Fedora (et RHEL) et que FireFox est le navigateur par défaut alors que Red Hat voulait initialement rester sur epiphany, que Red Hat est passé d'un panel dans gnome à deux, etc.
Red Hat peut se permettre d'être "audacieux" avec Fedora mais pas avec RHEL. Ceci n'empêche pas de faire de la fiabilité un critère important de Fedora.
Red Hat n'a aucun intérêt de faire de Fedora une sorte beta-produit car c'est la base de RHEL. Meilleur est Fedora, meilleur est RHEL. Red Hat l'a très bien compris.
[^] # Re: Incroyable...
Posté par Raphaël G. (site web personnel) . Évalué à 1.
J'ai opté sur la solution de rester perpétuellement en cooker pour voir mes bugs corrigés rapidement, après c'est le choix de chaqu'un, les versions "stables" de MandrakeLinux ont eu de gros soucis de stabilité chez moi (plantages aléatoires etc...), mais ce qui me plaît c'est que ça samméliorre au fur et a mesure donc je me pleind pas...
Ps : tu passe sous silence pas mal de truc que fait mandrake
Outil simple de config de service (bon config minimale ok)
Menu pas "dégeulasse" et rangé, pas comme sous d'autre distrib
Pas besoin de se prendre la tête avec des truc désactivé pour raison de secu parano, bien que parfois...
Et plein d'autre truc que j'oublie surement...
Allez urpmi.update -a && urpmi kernel-2.6.11.3mdk
pas de paquetage nommé kernel-2.6.11.3mdk
Et merde pas encore corrigé, bon on va rester en
kernel-multimedia-2.6.10-3.mm.4mdk-1-1mdk...
Allez un effort mandrake, la correction de ce bug serait pas de refus...
[^] # Re: Incroyable...
Posté par mdlh . Évalué à 0.
Ah bon.
[^] # Re: Incroyable...
Posté par Jiel (site web personnel) . Évalué à 3.
MandrakeSoft est une entreprise commerciale. Son but, comme toutes entreprsies commerciales, c'est de gagner de l'argent. Elle trouve divers moyens pour ça comme par exemple Mandrakelinux version download qui n'est disponible qu'1 ou 2 mois après la sortie pour le MandrakeClub.
Et alors? Moi ça me choque pas. Parce que MandrakeSoft a toujours respecté, depuis le début, et même dans les difficultés financières, le logiciel libre. Ce qui n'est pas le cas de SuSE avant le rachat par Novell, par exemple.
Support de KDE comme environnement par défaut mais applications Gnome ou GTK (evolution, totem, etc.) définies comme applications par défaut.
Et alors? Je pense que ce serait absurde de prétendre que toutes les applications KDE ou en Qt sont meilleures que celles de GNOME ou en GTK. Par exemple, Gaim me semble plus abouti que Kopete. Ce serait aussi pas très malin de ne pas inclure Gimp ou GnomeMeeting parce que c'est pas du KDE. Bref, on peut vouloir mettre du KDE et pas être complétement avec des oeillieres.
- Outils Drak* qui pourraient au moins bénéficier d'une interface en QT
Mais du coup on serait obligé d'installer Qt.
[^] # Re: Incroyable...
Posté par fabb . Évalué à 3.
Faut peut-être pas pousser. SuSE n'avais "que" yast avec une licence "bizarre". Le principale problème de la licence était de ne pas permettre un usage commercial.
Mandrake vend des produits proprio via MandrakeClub. Mandrake fournit le compilateur proprio d'Intel. Mandrake ne contribue en presque rien au logiciel libre en upstream (par rapport à SuSE, c'est le jour et la nuit). Mandrake ne fournit presque rien en ressource (hébergement de projet libre, etc).
SuSE a choisi une voie différente de Mandrake mais lorsqu'on fait le bilan on ne peut que se féliciter de la contribution de SuSE au logiciel libre.
Je n'utilise ni SuSE ni Mandrake. Mais je vois/apprécie les contributions de SuSE et je ne vois presque jamais les contributions de Mandrake.
[^] # Re: Incroyable...
Posté par zeb . Évalué à 3.
Vraiment ? Quel troll. Les contributions sont sur le wiki :
http://qa.mandrakesoft.com/twiki/bin/view/Main/FreeSoftwareProjects(...)
Mais evidemment, on peut leur reprocher de ne pas se vanter. Certains parlent beaucoup, d'autres agissent.
[^] # Re: Incroyable...
Posté par fabb . Évalué à 1.
Mais oui.
Pour la vantardise, trouves une page Red Hat ou Novell qui recense leurs contributions car je ne connait pas une telle page.
Pour ton info voilà les contributions de Mandrake pour Linux 2.6 (sur plus d'un an ! ) :
Comparaison :
[admin@one tmp]$ grep -i "^<.*osdl" ChangeLog-2.6.* | wc -l
4702
[admin@one tmp]$ grep -i "^<.*suse" ChangeLog-2.6.* | wc -l
1477
[admin@one tmp]$ grep -i "^<.*redhat" ChangeLog-2.6.* | wc -l
1054
[admin@one tmp]$ grep -i "^<.*ibm" ChangeLog-2.6.* | wc -l
863
[admin@one tmp]$ grep -i "^<.*intel" ChangeLog-2.6.* | wc -l
621
[admin@one tmp]$ grep -i "^<.*debian" ChangeLog-2.6.* | wc -l
159
[admin@one tmp]$ grep -i "^<.*gentoo" ChangeLog-2.6.* | wc -l
11
[admin@one tmp]$ grep -i "^<.*mandrake" ChangeLog-2.6.* | wc -l
2
Mandrake ne fait pas parti des nombreux membres de OSDL.
[^] # Re: Incroyable...
Posté par zeb . Évalué à 2.
[^] # Re: Incroyable...
Posté par fabb . Évalué à 1.
Très bien. Regarde toi même du côté de gcc/libc/gnome/kde/xorg et Mandrake est toujours un nain.
J'en veux pas à Mandrake mais j'en ai marre du pipeau qui répète que Mandrake est un gros contributeur alors que ce n'est pas le cas. Mandrake est un petit contributeur.
Le plus gros travail de Mandrake est de packager une distribution (comme beaucoup d'autres distributions).
Le plus gros travail de Red Hat ou SuSE est de développer des nouvelles fonctionnalités en upstream puis de les packager.
Je répète, je n'en veux pas Mandrake. C'est une petite boîte et packager une distribution c'est beaucoup de boulot pour leur effectif. Les effectifs de Red Hat ou SuSE étant beaucoup plus important (un rapport de 10) et sachant qu'ils ne font pas plus de distribution que Mandrake il est normal qu'ils aient du temps pour faire autre chose que "seulement" packager une distribution.
J'en ai marre du pipeau "Mandrake est un gros contributeur".
[^] # Re: Incroyable...
Posté par zeb . Évalué à 4.
Tu as l'air de me reprocher cela, alors que je ne l'ai jamais ecrit.
Mandrake emploie l'un des codeurs de KDE (pour couper court: kde-base, pas une appli satellite). Il y a aussi Warly, qui code un cdrecord libre capable de graver les DVD. Il y a aussi la completion auto dans bash, etc... Ce n'est pas "gros" pour certains (encore que la gravure des DVD ce n'est pas rien), mais beaucoup pourraient aussi ecrire qu'ils en ont marre de lire qu'ils ne font presque rien pour le logiciel libre, hein.
[^] # Re: Incroyable...
Posté par Larry Cow . Évalué à 4.
Mmmh, je n'ai pas dû utiliser Gaim depuis longtemps alors (et pourtant je ne jurais encore que par lui il y a une paire de mois). Parce que Kopete, au moins sur KDE3.3 (à plus forte raison en 3.4) lui tient la dragée haute. Je pense notamment au "browsing" des fonctionnalités Jabber, qui m'ont toujours terriblement manqué dans Gaim.
Qui plus est, vouloir faire un bureau KDE avec Gaim comme IM, ça serait limite balot, vu comme Kopete est bien intégré au reste de KDE (Kontact, tout ça).
[^] # Re: Et chez Mandrake ils font quoi ?
Posté par Bruce Le Nain (site web personnel) . Évalué à 4.
[^] # Re: Et chez Mandrake ils font quoi ?
Posté par neil . Évalué à -10.
[^] # Re: Et chez Mandrake ils font quoi ?
Posté par Kalimero . Évalué à 0.
Pour le reste, Mandrake s'oriente de plus en plus vers du "libre à deux vitesses", l'ADSL pour les membres du Club (qui payent pour ça) et le 56K pour les autres. Je trouve que c'est un peu dommage, mais il est vrai que le Club représente (du moins actuellement) la majeur partie de ses revenus. C'est d'autant plus dommage que le nouveau mode de développement de la Mandrake (Community avant Official) fait largement appel aux béta-testeurs de tous poils, pour un résultats dont seul les membres du Club bénéficient en primeur (et je ne pense pas qu'un ou deux rapports de bug suffisent pour se voir offrir un accès gratuit au Club)...
Sinon pour ton idée de maintenir quelques paquets, je suis pas sûr qu'un gars qui n'a jamais tapé une ligne de C/C++ de sa vie (par contre le Fortran c'était vraiment top ! ;-) ) soit très compétent pour ça. Après il se trouverait toujours des grincheux pour dire que Mandrake c'est de la merde et que les paquets non-officiels sont tous pourris ! ;-))))
[^] # Re: Et chez Mandrake ils font quoi ?
Posté par zeb . Évalué à 2.
Je pense que toutes les distros sont dans cette situation. Le DVD iso de Suse n'est pas vraiment accessible au 56K non plus :) Par contr tu peux commander des CDs directement a Mandrake, soit a des tiers, soit attendre que les CDs soient dispos dans une revue.
> Sinon pour ton idée de maintenir quelques paquets, je suis pas sûr qu'un gars qui n'a jamais tapé une ligne de C/C++ de sa vie
Maintenir des paquets ne signifie pas coder pourtant. Contributeur ne signifie pas mainteneur ou codeur. Il s'agit d'utiliser rpm et d'ecrire un spec correct. Et pour ce faire, le wiki de cooker donne toutes les instructions.
Par ailleurs, les paquets contrib ne sont pas acceptes aveuglement. Il y a des outils (comme rpmlint et autres) qui permettent de verifier que les dependances sont correctes, que le spec est correctement formate, etc... et le paquet n'est uploade que lorsqu'il passe les criteres. Bien sur parfois il y a des problemes. Mais bon quand c'est non-officiel...
Au fait, je n'ai jamais dit que 2 rapport de bugs suffisaient pour devenir membre. Par contre maintenir un ou deux paquets dans contrib (de facon suivie et de qualite quand meme), oui. Un recensement de tous les contributeurs est fait avant chaque release d'ailleurs. Voila ;)
[^] # Re: Et chez Mandrake ils font quoi ?
Posté par Kalimero . Évalué à 1.
Pour ce qui est de maintenir des paquets, il suffit de jeter un coup d'oeil à celui de K3B que j'ai voulu recompiler sur ma 10.1 depuis le .src.rpm de cooker, c'est de la belle ouvrage avec une bonne dizaine de patches dans tous les sens et un spec long comme une description de Balzac ! Et ça, moi, soyons modeste, je sais pas faire !
Pour le reste, je tiens à préciser que j'aime vraiment bien Mandrake, que j'ai commencer à bidouiller dessus avec la 8.0, que j'ai réellement basculé avec la 9.1 (Powerpack, tiens, tiens !) mais que je suis un peu décu par leur dérive un peu trop commerciale à mon goût, c'est tout. Et si je lorgne du côté d'Ubuntu, je pense que je resterai encore un moment avec Mandrake, dont la qualité, à iso-configuration de Pc, s'est globalement bien améliorée.
Putain, ça se voit que c'est la printemps, si ça continue je vais finir par rouler une galoche à Warly ! ;-)
[^] # Re: Et chez Mandrake ils font quoi ?
Posté par neil . Évalué à -7.
Doit y avoir des gens de chez Mandrake :p
[^] # Re: Et chez Mandrake ils font quoi ?
Posté par fabb . Évalué à -4.
[^] # Re: Et chez Mandrake ils font quoi ?
Posté par zeSixty4Douille . Évalué à 1.
Par exemple KPDF, amaroK, les patches dans KHTML, et pour x86 et x86-64, la limitation du scoping des symboles (demarrage + rapide).
J'aime vraiment KDE, mais au lieu de conseiller SuSE sans arguments (autre que le numero de version), il aurait fallu qu'une personne test la version 64-bit de la Mandrake 10.2 (ou LE 2005) par rapport a la SuSE 9.2.
Sinon il y a aussi la KLAX quii est pas mal, qui fonctionne mieux chez moi qu'une Ubuntu.
[^] # Re: Et chez Mandrake ils font quoi ?
Posté par Prosper . Évalué à 2.
Amarok ne fait pas partie des release KDE ( et ne le saura probablement jamais comme k3b ) .
# kpdf
Posté par udok . Évalué à 5.
notamment les deux nouvelles fonctionnalités :
- possibilité de voir les pages en continues
- possibilité de sélectionner du texte ou des images au choix
[^] # Re: kpdf
Posté par anonimulo . Évalué à 10.
Malheureusement, il est désactivé par défaut, mais il suffit de faire :
$ ./configure --enable-force-kpdf-drm
et le tour est joué !
Si ce n'est pas vous qui avez compilé, rien n'est perdu ! Vous pouvez demander à votre admin d'aller dans kiosk (l'outil d'administration de KDE pour restreindre la configurabilité du bureau lorsque c'est souhaitable).
Il y a une option : skip_drm, valant malheureusement YES par défaut, ce qui a pour effet de laisser l'utilisateur configurer s'il veut respecter les DRM ou pas.
Pas de panique ! Changez cette valeur pour NO et la propriété intellectuelle sera respectée.
J'espère que les autres visualisateurs PDF supporteront cette feature présente depuis longtemps dans XPDF
Cf : http://www.foolabs.com/xpdf/cracking.html(...)
Je pense notemment à Evince pour gnome, ou au fork d'XPDF réalisé par freedesktop.
[^] # Re: kpdf
Posté par mickabouille . Évalué à 3.
Je ne vois pas ce que ça a à voir avec le respect de a propriété intellectuelle en fait
[^] # Re: kpdf
Posté par fasthm . Évalué à 5.
La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
[^] # Re: kpdf
Posté par mickabouille . Évalué à 3.
Ça va mieux là...
[^] # Re: kpdf
Posté par dudule42 . Évalué à 1.
Ça sert à quoi d'activer soit même une limitation des actions possible ?
Je veux bien qu'Adobe le demande/éxige pour respecter pleinement la spec PDF mais quand même.
Je trouve ridicule de forcer les utilisateurs à imprimer le document dans un fichier (ou faire une copie d'écran si l'impression est DRMisée) et à utiliser un logiciel de reconnaissance de caractère pour récupérer le texte.
DRM = Digital Restriction Management
[^] # Re: kpdf
Posté par anonimulo . Évalué à 6.
Blague à part, l' info à retenir, c'est que un contributeur de kpdf a cru bon d'implémenter les restrictions drm, et que le projet KDE n'a pas cédé au politiquement correct, et a promptement désactivé ça, ce qui est une bonne nouvelle je trouve.
# pourquoi virer autotools ?
Posté par udok . Évalué à 4.
les autotools permettent notamment de maintenir un environnement de production permettant de compiler aisément des sources pour plusieurs architectures différentes sans apporter de modif particulière à cet environnement
chez debian, ils demandent avec insistance à ce que les programmes packagés utilisent autotools pour permettre de packager automatiquement pour plusieurs plateformes, donc si ils virent ça, ça risque de poser pb au moins sur debian (mais sans doute aussi ailleurs, quid de gentoo et autres ... ?)
[^] # Re: pourquoi virer autotools ?
Posté par gnumdk (site web personnel) . Évalué à 0.
[^] # Re: pourquoi virer autotools ?
Posté par udok . Évalué à 1.
bon l'interet d'autotools c'est d'harmoniser cette tache entre les différents programmes
je suis conscient que c'est pas parfait, mais plutot que de réinventer la roue à chaque fois qu'un truc ne va pas dans un logiciel (ça arrive souvent qu'il existe bcp de prog pour faire la même chose ... alors le choix c'est bien mais faut pas que ça empeche d'unir les forces en présence)
je critique pas la (future) démarche de l'équipe kde (je me permettrais pas vu mon niveau), mais n'était-il pas possible/préférable de faire évoluer autotools plutot que de refaire un équivalent, ce qui va nuir à l'harmonisation dans ce domaine (et accessoirement emmerder debian)
[^] # Re: pourquoi virer autotools ?
Posté par Superted . Évalué à 4.
Les autotools sont d'un complexité incroyable. C'et typiquement le genre d'outils qui semble avoir évolué de manière démeusuré et tentaculaire depuis trop longtemps. Le seul problème avec c'est que ça marche ;-).
Parce que au final c'est chiant à utiliser mais ça permet de distribuer des sources qui vont pouvoir être compilés sur pleins de plateformes, ce qui est génial ! Mais c'est tellement énorme comme truc que le modifier pour en faire quelque chose de simple c'est pas réellement possible.
Mais avoir un autre outils aussi puissant et plus élégant ne serait pas un mal.
Pour faire un parallèle ça me rappele sendmail qui est lui même très puissant, mais complexe à configurer.
[^] # Re: pourquoi virer autotools ?
Posté par Philippe F (site web personnel) . Évalué à 8.
Pour te repondre, je te redonne un bon dicton d'informaticien: "Il ne faut pas reinventer la roue. Sauf quand le premier inventeur a invente une roue carree".
autotools, c'est clairement une roue carree. C'est un arrachage de cheveux a maintenir. Parmis les milliers de contributeurs et parmi la quarantaine de developpeurs principaux de KDE (qui ont un sacre niveau en informatique), il y a en tout et pour tout deux developpeurs qui comprennent completement le systeme des autotools utilise par KDE et qui sont capables de le maintenir. Ca ne fait pas beaucoup.
Les developpeurs de KDE ne prennent pas des decisions techniques a la legere. Si ils se debarrassent d'autotools, c'est que ce n'etait plus gerable.
Il y a des super projets pour remplacer autotools, qui ont tous la caracteristiques d'etre simple a utiliser et simple a faire evoluer. Deux qualite qui manquent terriblement a autotools. Je peux te dire que le type qui s'occupe d'autotools pour KDE (il me semble que c'est Stephan Kulow) est super motive pour utiliser autre chose, pour te donner une idee du truc.
Scons semble etre une alternative interessante. Il y en a d'autres. Pourquoi se prendre la tete avec un systeme super complexe quand des alternatives plus simples existent.
Faut pas etre trop sentimental. Autotools etait une bonne solution au moment ou il a ete cree, mais aujourd'hui, l'outil ne fait plus le poids. Avoir python ou perl installe sur sa machine n'est pas une contrainte extraordinaire alors qu'a l'epoque ou autotools a ete cree, sh etait la seule dependance acceptable.
Par exemple, je suis toujours choque que ./configure ne detecte pas les erreurs de syntaxes dans ses options:
./configure --enable-truc-muche ne te renverra aucune erreur. Sauf que en fait, il fallait taper:
./configure --enable-trucmuche
Et encore, ca c'est un probleme mineur d'utilisateur, rien a voir avec la complexite de la mise en place du truc.
[^] # Re: pourquoi virer autotools ?
Posté par fabb . Évalué à 1.
> il me semble que c'est Stephan Kulow
J'ai l'impression que les gens s'emballent pour rien. Si c'est pour unsermake, il ne remplace "que" automake.
- "Unsermake is a replacement for automake by KDE developer Stephen Kulow."
- "Unsermake replaces automake but keeps everything else, including the strange Makefile.am syntax the same."
[^] # Re: pourquoi virer autotools ?
Posté par fabb . Évalué à 1.
[^] # Re: pourquoi virer autotools ?
Posté par Philippe F (site web personnel) . Évalué à 2.
Le but de se debarasser d'autotools, c'est probablement de passer de 12 etapes a 2, et de beneficier en sus d'ameliorations de performances diverses au niveau de la compilation.
Je ne connais pas bien le sujet, mais j'ai entendu dire que le fait que make n'est qu'une vision repertoire par repertoire rend pas mal d'optimisations (distribution de la compilation, blocage de certains morceaux de la compilatino, ...) plutot difficiles.
[^] # Re: pourquoi virer autotools ?
Posté par Sebastien . Évalué à 2.
Ensuite, il me semble que la gestion de l'ordre de compilation des paquets, la possibilite de faire de la compilation parrallele (sur plusieurs machines et/ou sur plusieurs paquets) et autres optimisations doit etre efftectuee par une couche au-dessus : CMT, unsermake ou autre.
[^] # Re: pourquoi virer autotools ?
Posté par spart . Évalué à 3.
> compilation au compilateur
en fait ce qu'un développeur attend de lui, c'est surtout qu'il ne recompile pas les 3/4 de ton arbre local au moindre changement si ce n'est pas strictement nécessaire.
Avec un make récursif, la gestion des dépendances inter-répertoires est lente et très aléatoire.
[^] # Re: pourquoi virer autotools ?
Posté par herodiade . Évalué à 2.
C'est un remplaçant entièrement en C pour autotools, libtool et pkg-config. C'est très éléguant, très rapide, très simple à utiliser, et ça diminue encore les dépendances et les problèmes liés au shell script (par rapport à autotools, ou python pour scons etc.).
On peut supposer qu'il pourrai facilement être porté sur des plateforme win32 (plus que les shells scripts auto* pour sûr ;) même si ce n'est pas un objectif immediat.
Je serai ravi que plus de developpeurs l'utilisent, en raison de l'objectif principal du projet: être irreprochable sur la sécurité pour l'utilisateur. Ça fonctionne sur la base de fichiers de description (parsés et 'éxecutés' par l'outil en C) avec bien entendu un nombre d'actions et de possibiltés prédéfinies et limités, bien étudiées. Il est censé ne pas permettre de faire des choses dangeureuses.
En effet il ne faut pas oublier qu'un script configure est toujours susceptible de vous installer une rootkit en loucedé (ou jouer avec votre courriel ou ....). Les scripts configure (et libtool) sont très gros et complexes, en pratique très penibles à auditer ; comme c'est du shell script, tout leur est permis. Pensez-y quand vous installez à la main un nouveau logiciel ...
[^] # Re: pourquoi virer autotools ?
Posté par Sebastien . Évalué à 2.
mais CMT est ecrit en C++, deja porte sous win32 et solaris (pour solaris je m'avance un petit peu, j'en avais entendu parle, j'ai vu des bug reports, mais...), il me semble qu'il y a aussi possibilite de le scripter via python et une GUI (Visual CMT) est disponible.
CMT lit lui aussi un fichier (habituellement appele requirements) dans lequel tu donnes les dependances aux paquets de ton appli, dans un langage relativement simple :
use MonPaquet MonPaquet-00-00-01 Chemin/dans/larbo/rescence/de/mon/appli/vers/mon/paquet
(sur une ligne)
et puis tu lui dis ce que tu veux faire, un shared object, une appli static...
La syntaxe est relativement simple (meme un physicien un peu bete comme moi peut s'en servir :)
Ensuite c'est juste une affaire de configuration d'un (ou quelques) paquet mere dans lequel tu mets toutes les regles de compilations, les differentes actions que tu peux vouloir faire (creer la doc doxygen, lancer des scripts de pre/post-installation, configurer l'environnement de travail du developpeur (runtime, include paths,...), etc...)
De plus CMT ce n'est pas *que* un programme pour compiler une appli, cela sert aussi a interagir avec ton appli (dans le sens demander quelles sont les dependances de tel paquet, ses clients,...)
C'etait un message a caractere informatif.
[^] # Re: pourquoi virer autotools ?
Posté par Sebastien . Évalué à 4.
Un peu de respect quand même ;)
Ce gars là c'est Stephan Kulow, release manager de KDE...
[^] # Re: pourquoi virer autotools ?
Posté par Alex . Évalué à 1.
En fait ils trouvent qu'autotools est trop rude à maintenir, et qu'il est trop dur d'y "renter". Mais a prioris ils vont peut etre utiliser unsermake (par un gars de kde) mais ca sera surement scons ou cmake
[^] # Re: pourquoi virer autotools ?
Posté par Pinaraf . Évalué à 6.
En effet, il semblerait que rien qu'en filtrant l'affichage, on arrive à réduire la durée de compilation de quelques pourcents même sur un PC récent, parce que les console sont très très lentes !
De plus, un configure qui prend 1 minute à tester 100 trucs ... c'est gonflant, surtout quand il le fait 15 fois !
[^] # Re: pourquoi virer autotools ?
Posté par Sebastien . Évalué à 4.
Après une rapide lecture de la page, ce que j'en conclus c'est qu'ils veulent un peu plus rationaliser et factoriser le processus de compilation : regrouper les options de compilation dans un seul (gros?) Makefile.
Moins de Makefile disséminés un peu partout dans l'arborescence.
C'est quand même dommage de réinventer la roue avec unsermake : il y a déjà CMT[2] qui existe (quoi je ne vous ai pas encore parlé de CMT? Mais si regardez mes derniers journaux...) et qui est bien dimensionné pour les gros projets.
[1] http://www.kde.me.uk/index.php?page=unsermake(...)
[2] http://www.cmtsite.org(...)
[^] # Re: pourquoi virer autotools ?
Posté par spart . Évalué à 3.
Au début, c'était juste une expérience, mais les gains se sont avérés si substantiels que beaucoup de développeurs l'ont adopté au quotidien.
[1] http://webcvs.kde.org/kdenonbeta/unsermake/doc/auug97.pdf?rev=1.1&view=auto
[^] # Re: pourquoi virer autotools ?
Posté par Croconux . Évalué à 4.
Pas forcément. Ce qui emmerde le plus les développeurs c'est tout le bordel de macro M4 absolument imbitable. Pour les mainteneurs de paquets, l'important est de pouvoir modifier les options de compilation, notamment les chemins (--bindir=, --prefix) et activer/désactiver des composants optionels (--with-xxx, --without-xxx). Le packager se fout de savoir avec quoi le script configure a été généré du moment qu'il s'utilise de la même façon (./configure --plein-de-chose && make && make install). Il suffit de garder la même syntaxe pour les commandes et options et de remplacer les truc.in et machin.am par quelque chose de plus simple.
[^] # Re: pourquoi virer autotools ?
Posté par Raphaël G. (site web personnel) . Évalué à 1.
--enable-something (avec du --with ou autre tant que ça marche)
--prefix (tout les prefix modifiables, pour mettre les fichiers de conf dans /etc ou autre selon le paquet, etc...)
et une option pour installer le paquet dans un rep de destination sans se casser la tête a bouger 50 fichiers a la mais parce que le script marche pas...
parce que honetement après le 50ème install --permission en tout genre tagada/src/machin.so RPM/DEB/ETC_ROOT_DIR/bonchemin(tm)/machin.so.bonneversion c'est super lourd!!!
Perso j'aime bien les autotool et ça marche pas mal.
Et si vous voullez pas vous casser la tête utilisez kdevelop pour créer votre projet avec, d'accord c'est lourd mais ilvous gère tout le bouzin très bien dans la plupart des cas sans se prendre la tête avec les dépendances en tout genre...
# Ubuntu
Posté par Flink . Évalué à 7.
Ubuntu décidemment c'est Bien (tm)
[^] # Re: Ubuntu
Posté par Ozz . Évalué à 4.
sudo apt-get install kubuntu-desktop
c'est facile, mais faut le savoir.
par defaut les polices ne sont pas anti-aliasées (bug), c'est juste une option à cocher dans kcontrol.
[^] # Re: Ubuntu
Posté par Pierre Habouzit . Évalué à -1.
(rendons à césar ce qui lui appartient)
# Vidéos
Posté par gnumdk (site web personnel) . Évalué à 4.
Deux ptites vidéos de présentation de KDE 3.4
[^] # Re: Vidéos
Posté par Taku . Évalué à 1.
pour ma part je suis plutot Gnome, mais il est vrai que sur la gestion de la transparence, et des outils de configuration KDE se debrouille vraiment pas mal ...
dommage que le cycle de release soit totalement debianesque et que QT4 mette tant de temps a venir ... d'ailleur il est prévu pour quand et avec quelles améliorations en gros ?
Appel à témoins :) .
[^] # Re: Vidéos
Posté par qdm . Évalué à 2.
Qt 4 est prévu en finale pour juin je crois. Donc le temps de tout porter vers le 4, on aura "en théorie" une 3.5 pour une date indéterminée vers la fin de l'année et un KDE 4 dans le courant de l'année suivante.
# Férus de screenshots
Posté par Anonyme . Évalué à 2.
[^] # Re: Férus de screenshots
Posté par Sylvain Briole (site web personnel) . Évalué à 5.
# Autre petits plus
Posté par Victor STINNER (site web personnel) . Évalué à 1.
* SVG files can now be used as wallpapers
C'est vachement sympa ça ! C'est le premier gestionnaire de fenêtres qui supporte les fonds d'écran vectoriels, ou bien ?
Haypo
[^] # Re: Autre petits plus
Posté par gnumdk (site web personnel) . Évalué à 2.
2- Ca fait un moment que gnome le supporte(le svg)
# Grande nouvelle pour les Gentooistes
Posté par iznogoud . Évalué à 3.
Voir : http://gentoo-portage.com/kde-base(...) pour s'en convaincre, au lieu des trois ou quatres gros paquets monolithiques, on dispose de plusieurs paquets, un par application.
Note : pour KDE < 4.0, l'ancien système avec les paquets monolithiques restera.
Un petit lien utile, traduit par votre serviteur :
http://www.gentoo.org/doc/fr/kde-split-ebuilds.xml(...)
Qui explique le pourquoi du comment.
Faites chauffer votre Portage :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.