Julien MOROT a écrit 278 commentaires

Le code y est à 99 % indépendant de la plate-forme, ce qui la rend sans doute plus attractive pour les développeurs...

Pour ce qui est des toolkits portables, je vois pas en quoi wxwidgets est plus attractif que Qt ou GTK. Je dirais même le contraire vu la clarté de l'API de Qt et GTK et l'affreuse API de wxwidgets.

Gnome est pas dans une position très enviable en ce qui concerne les languages de haut niveau aussi. D'un côté tu as RedHat, principal contributeur à Gnome et qui mise sur java avec gcj et classpath. De l'autre tu as Novell qui mise sur Mono, choix qui a la préférence de la communauté, mais RedHat ne veut pas entendre parler de Mono. Bref, c'est un beau bordel.

Je ne peux que te pertinenter!

J'avais vu la discussion sur debian-devel mais je croyais que ça n'avait pas abouti! Merci!

Un autre point qui me chagrine malgré ses nombreuses qualtiés c'est ça au démarrage de clamav :

LibClamAV Warning: ********************************************************
LibClamAV Warning: *** This version of the ClamAV engine is outdated. ***
LibClamAV Warning: *** DON'T PANIC! Read http://www.clamav.net/faq.html(...) ***
LibClamAV Warning: ********************************************************

Debian est également la distribution qui fournit le plus grand nombre de paquets, environ 15000

Malgré l'immense respect que j'ai pour Debian, que j'ai d'ailleurs sur mon portable et mon serveur, mon desktop étant en gentoo, il faut voir aussi comment Debian compte les packages.

Pour un package toto, tu auras libtoto libtoto-dev toto-extras toto-sounds toto-doc etc... Donc forcément le comptage est un peu biaisé. Je ne nie pas malgré tout les avantages que peuvent avoir la segmentation d'un package en plusieurs packages. C'est juste pour rétablir une exactitude.

Et même si certains paquets de Etch sont liés avec libselinux ça ne signifie absolument pas que la Etch utilisera selinux par défaut.
Par contre ça permet d'avoir une infrastructure de sécurité supplémentaire.
Après si le libre veut conserver son leadership de la sécurité il faut qu'il s'en donne les moyens. OpenBSD le fait, il n'y a pas de raisons pour que ce soit un mal dans les distributions linux.

Alors tu utilises le live cd qui gère reiser4 pour l'installer :

http://gentoo-wiki.com/TIP_Reiser4_Enabled_Live_CD(...)

http://www.linuxfr-france.org.invalid/prj/imapsync/(...)

Petite correction :
Autant pour TrustedBSD, SEBSD et Privnam ce sont bien des produits McAfee, d'ailleurs en bas du site de TrustedBSD, on voit bien un joli :
"Copyright 2002, 2003 Networks Associates, Inc. All rights reserved."

Autant SELinux c'est un pur produit de la NSA et depuis quelques temps avec un large soutient de RedHat.

Mes félicitations à l'auteur de la news.
Elle est très complète claire et détaillée. Elle donne envie de la lire et de s'interresser au projet!
Longue vie à Neogia!
Dommage que certains journaux d'une ligne ne s'en inspirent pas un minimum...

KDE sous Fedora est beaucoup critiqué vu comment il est affreusement configuré. Surtout comparé à Gnome qui est très joliment peaufiné.
Cela permettra peut être de remettre les choses un peu à égalité à ce niveau pour ceux qui apprécie la Fedora mais qui préfèrent KDE comme DE.

Il y a bien http://kde-redhat.sourceforge.net/(...) pour fournir un joli KDE pour fedora mais comme ce n'est pas intégré par défaut ce n'est tout de même pas des plus pratique.

+1 Les schémas de base LDAP sont normalisés dans des RFC de toute façon.
Pour les autres schéma, si le schéma de base change régulièrement je vois pas comment on peut s'apuyer dessus, après rien n'empêche d'étendre ces schémas, mais c'est une autre histoire.

patience, la version 2.3 d'OpenLDAP stockera _tout_ dans la base. Enfin ! :-)
Je ne vois rien de tel dans la roadmap de openldap tu peux donner une indication stp?
http://www.openldap.org/software/roadmap.html(...)
Si tu dis vrai, ce serait le paradis :)

sinon, si tu t'attendais à ce que les développeurs d'OpenLDAP codent une interface graphique, ce serait contraire à l'esprit de tous les serveurs classiques sous Unix, d'ailleurs quel toolkit utiliser ? motif ?
Non, juste un truc moins disséminé entre les différents programmes (genre schémas, scripts & cie), des outils un peu plus haut niveau et une meilleure coopération avec les différents projets utilisant ldap afin d'avoir une meilleure intégration.

Voici la thèse d'Andrew Bartlett, l'un des développeurs principaux de Samba, pas mal d'info interressantes en plus à part ça sur le futur de Samba :
http://samba.org/samba/news/articles/abartlet_thesis.pdf(...)

LDAP sous Linux c'est assez hasardeux en effet et tout comme toi j'y centralise le plus de choses possibles sur mon serveur. Les deux gros points noirs que j'y vois sont que :

- tu peux faire ton schéma et agiter les bras pour que les autres acceptent de l'utiliser mais la tendance est que les développeurs s'investissent assez peu pour ça. J'avais reporté un memleak dans le patch ldap pour bind, et le développeur du patch m'avait avoué déplorer l'architecture de bind pour stockerles zones ailleurs que dans des fichiers textes.

- OpenLdap ressemble davantage à un méta annuaire pour programmeurs qu'à une solution administrable. C'est à ce propos la raison pour laquelle les développeurs de Samba ont préférés refaire leur propre serveur LDAP à cause de la mauvaise volonté des développeurs d'Openldap. D'ailleurs je trouve qu'il manque un certain nombre de fonctionnalités fort utiles en production comme la réplication multi maitres et plus encore le stockage des ACL et du schéma dans la base. Si tu modifies l'un des deux, redémarrage obligé de l'annuaire, c'est pas top top.

Personnellement j'apprécie beaucoup un petit logiciel nommé luma :
http://luma.sourceforge.net/(...)

En plus, le développeur est vraiment un chic type.

Si je ne suis pas depuis un poste Linux, j'utilise phpldapadmin mais ca a ses défauts :/

Ton raisonnement est valable pour un logiciel en cours d'écriture.
Ici, les fonctionnalités sont plus ou moins terminées et OOo est plutôt entré en cours de débuggage.
Sachant qu'OOo est déjà en retard, la documentation n'ajoutera que du retard. Ce n'est pas comme si le projet en était à son début et qu'un nouveau contributeur X souhaite ajouter une fonctionnalité non prévue ou pas encore codée et donc il ne ralenti pas (moins?) les autres développeurs à travailler en parallèle.

Le problème c'est que tu risques de te prendre la loi de Brooks à la figure de cette façon.
Pour rappel, cette loi énonce que rajouter des développeurs à un projet en retard ne fait qu'accentuer le retard du fait que les impératifs de communications venant accentuer ce retard.
http://www.linuxfr-france.org.invalid/prj/jargonf/B/Brooks_Frederick_P.html(...)

Mais 95% des utilisateurs n'ont pas de cerveau, je vois ça tout les jours à la hotline que je tiens.
Et pour les gens qui "savent utiliser", de ce que j'en vois, ils apprennent plus à mémoriser une séquence de clics qu'à réfléchir aux fonctionnalités d'un traitement de textes et donc à ce qu'ils font.

Consternant.

Bien sûr que si il est dispo, depuis 4 jours même.
Par contre il faut fouiller dans le répertoire perso de Greg Kroah Hartman ce qui est bien dommage vu l'objectif fixé par cette branche...

ftp://ftp.kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/(...)

"A quand une version pour Linux ?"

C'est pas libre, c'est pas intégré à l'environnement de bureau et ça n'indexe pas les fichiers Gnome/K/Open office alors à quoi bon?

Par contre pour les gnomistes Beagle a l'air de déjà bien marcher, d'être intégré à évolution et gaim sans les défauts de google desktop search alors à quoi bon?

Et à propos d'alsa, les cartes son SBLive à base de chip emu10k1 bidouillées par dell fonctionnent désormais sous Linux.

http://linuxfr.org/comments/536506.html#536506(...)

Au contraire on commence déjà à voir le résultat des apports des derniers serveurs X. Par exemple ici pour KDE 3.4 :

http://bssteph.irtonline.org/kompmgr_and_kde_window_eyecandy_mpeg(...)
Ou ici pour le lien direct mais je ne pense pas si il passera avec les espaces :
http://bssteph.irtonline.org/filestore2/download/226/kompmgr(...) and KDE - window eyecandy.mpeg

Et comme Cairo devrait être géré par GTK et Qt à terme, avec glitz en backend on devrait avoir des choses plutot interressantes.

En fait un serveur X basé sur OpenGL n'est qu'un des différents points développés pour réarchitecturer le fonctionnement de X.
Keith Packard a expliqué ceci dans un document :
http://keithp.com/~keithp/talks/xarch_ols2004/xarch-ols2004-html/(...)

Pour résumer les points principaux sont :
Dégager la xlib en faveur d'une lib asynchrone : XCB
Placer opengl comme base du serveur X.
Utilisation de cairo pour faire des rendus en vectoriels, glitz étant un backend opengl pour cairo.
Revoir la sécurité de X avec notamment SELinux.
Améliorer l'aspect eye candy avec Damage et Composite
Améliorer le sous système de fonts.
Inclure un driver pour la carte graphique au niveau du kernel pour notamment unifier la gestion de l'accès au périphérique graphique.