Les sources de yast ont toujours été livrés avec la distribution. Tu peux copier yast mais tu ne peux pas modifier.

[ Répondre ]

> les utilisateurs qui veulent la découvrir (dans ce cas l'installeur debian doit etre le plus user-friendly)

Je considère depuis quelque temps que, "quelque part", Debian est en train de faillire dans sa "mission". Faire un OS libre (et non seulement au niveau source) et uniquement pour une élite est contradictoire.

> En relisant les posts on voit bien la fracture entre ces deux mondes, les utilisateurs standart qui veulent quelque chose de tres fun et facile d'utilisation

Pour info, je suis un utilisateur de GNU/Linux de longue date (Linux 1.2) et je suis développeur. Installer une Debian n'est pas une difficultée pour moi. De plus, je n'utilise pas Linux pour le "fun". C'est mon OS exclusif chez moi depuis 1997 et je travaille principalement dessus (avec les Unix commerciaux).

Ce qui fait que je n'utilise pas Debian (qui est ma distribution N°2) est quelle est compliquée même quand ce n'est pas nécessaire. Une ------ (ou Mandrake ou suse, ou ...) est simple tant quelle peut le rester et compliquée comme tout système Linux lorsqu'on veut aller plus loin. Mais pour faire du compliqué, il faut avoir une démarche volontaire (curiosité, problème à résoudre, etc...) . En gros une Debian c'est à 98 % la même chose que les autres distributions. Mais les 2 % qui reste, qui sont visible par tout le monde (l'élite et le newbi), est inutilement compliqué. Il faut que la partie compliquée (aussi puissante soit-elle) ne soit pas un passage obligatoire.

Enfin il ne faut pas laisser croire qu'une ------ ou une Suse sont des distributions pour le fun. Leurs cibles prioritaires sont les entreprises et les serveurs, et elles se débrouillent bien dans ce domaine et n'ont pratiquement rien a envier techniquement à Debian.

> je prefere qu'il compare a redhat qu'a windows.

La "référence" choisie est pour rendre les choses plus concrète. Même si j'installe une distribution pour un serveur, je n'ai pas envis de me prendre la tête lors de l'installation avec des questions "exotiques". J'installe un serveur en 3 clicks puis je me prends la tête avec httpd.conf, php, gcc, postgresql ... Et si ça prend trop de place sur le disque dure, je supprime des paquets (mais vu la taille des disques dures c'est rare, c'est même très rare).

Je sais compilé un noyau mais lorsque ce n'est plus devenu nécessaire, j'étais bien content de ne plus "perdre" mon temps à ça et me consacrer directement sur ma mission. Et tant pis si pour la mémoire ce n'est pas le top et si je perds 1% en performance.

Des tas de développeurs rendent Linux de plus en plus simple mais il y a des utilisateurs qui ne veulent pas ça. Pourquoi ? Je ne suis pas sous GNU/Linux pour faire rebelle ou élite mais car c'est un OS libre et de qualité.

[ Répondre ]

Que tu me dises que lwn.net n'est pas la source de référence pour gentoo n'est vraiment surprenant.

Que gentoo fournisse une liste de diffusion pour les trous de sécurité est d'une banalité affligeante.

Que tu restifies le fait que Gentoo a déjà fait un correctif contrairement à ce qu'indique lwn.net, est parfait et bienvenu.

Que tu ne sois pas très heureux que Gentoo soit pointé du doigt est compréhensible.

Par contre que tu critiques lwn.net est nul.
lwn.net fourni peut-être la meilleur synthèse sur les trous de sécurités. Qu'il générère un peu de compétion entre les distributions est bienvenu. De plus si un jours Gentoo traine *réellement* pour faire un correctif, comment tu le sais si ta seule source d'information c'est Gentoo ?

Ce trou de sécurité je l'ai apris sur lwn.net. Et je peux te dire que ma distribution préférée n'a pas encore de correctif (source lwn.net et officielle). Que lwn.net lui mette un peu de pression ne peut pas lui fait de mal.

[ Répondre ]

Merci pour l'info. De plus on peut penser que Novell a réflechit à la question.
Néanmoins même si Havoc a tord (ce qu'il annonce dès le début "Hopefully it will start a discussion and become rapidly outdated"), je trouve qu'il pose le "débat" sur le futur de Gnome sur de bonnes bases (c-à-d sans oublier d'éléments importants). J'espère que quelque chose de fédérateur sortira de tout ça et que Gnome s'engagera solidement vers la bonne direction. Car actuellement c'est le flou et aucune décision n'a été prise par rapport aux nouvelles technologies type .NET, XAML, etc... qui semble gagner en popularité.

[ Répondre ]

> 1 des objectifs de MDI c'est de pouvoir proposer un API indépendant du langage, entendre par là ne pas avoir à supporter plusieurs bindings.

J'ai parfaitement compris ça. C'est la même chose que .NET.

> Pour ce qui est d'utiliser les librairies .NET de Microsoft, je vois pas trop, vu que MDI s'acharne à tout réécrire...

Il est là le problème. MS à des brevets sur .NET (et pas sur CLI et C#).

De l'article :
Microsoft has set a clever trap by standardizing the core of the CLI and C# language with ECMA, while keeping proprietary the class libraries such as ASP.NET and XAML. There's the appearance of an open managed runtime, but it's an incomplete platform, and no momentum or standards body exists to drive it to completion in an open manner. Many interesting class libraries are clearly encumbered by Microsoft IP and nobody concerned about legal liability will want to ship them. The core may also be encumbered, though that remains uncertain.

Aside from IP issues, Microsoft controls the .NET platform. They will always be ahead, and it will always be tuned for Windows. This is the wrong direction for free software, if we want to win the war, and not only some battles.

Even if we use some unencumbered ideas or designs from the .NET world, we should never define our open source managed runtime as a .NET clone.

If we built on the ECMA core, it would be critical to launch a large-scale effort to standardize and market a comprehensive alternative API set to replace the Microsoft-encumbered class libraries. This would be a heck of a lot of work.

> c'est ici juste pour la compatiblité
Si c'est compatible (je parle de .NET et non de C#) il y a problème.
Je parlais d'"implémenter" .NET dans Gnome. Je ne parlais pas de copier les fichiers des classes .NET d'une machine Windows avec Licence MS sous Linux.

[ Répondre ]

> Pour faire une news, il faudrait peut-être attendre qu'elle soit dispo.
> Mais quand elle sortira j'essairai l'install par ftp

On attend pas que Mandrake soit dispo en ftp pour en parler :
http://linuxfr.org/2004/03/12/15633.html(...)
Ca vient à peine d'être annoncé sur le site de Mandrake Linux : la toute nouvelle "Mandrakelinux 10.0 Community" est déjà disponible pour les membres du Club Mandrake et les contributeurs (développeurs, traducteurs...). Une version publique sur FTP sera disponible un peu plus tard

Appliquons la même chose pour tout le monde. Le problème d'attendre la disponibilité via ftp (ou autre) est que l'on fait l'impasse sur certaines distributions (lindows par exemple).

Je pense qu'il ne faut pas parler d'une distribution tant que les sources (au moins ceux sous (L)GPL) ne sont pas disponibles. Comme j'ai jamais vue les sources de Xandros et Lindows, je ne suis pas contre de faire un boycott. Ou alors seulement passer les news qui parlent de l'absence des sources :-)

[ Répondre ]

> void *f( int a ); -> f renvoie un void * ou f est un pointeur de fonction ?

C'est une déclaration de fonction qui retourne un (void *) et attend un int en paramètre.
Le problème ici c'est qu'il n'est pas obligatoire d'utiliser extern comme pour les variable pour lever l'ambiguïté.
Ainsi :
int i ; <= définition
extern int i ; <= déclaration
void *f(int a) ; <= déclaration
extern void *f(int a) ; <= toujours déclaration
de plus les fontions ont un traitement particulier :
void * (*t)(int) = f ;
void * (*u)(int) = &f ;
t(10) ;
u(10) ;
Les deux marches.
Il n'y a pas de variables fonction mais que des pointeurs de fonction. Une définition de fonction est toujours une définition d'un pointeur de fonction (c'est bizarre). Donc il faudrait écrire *t(10). Mais ça ne marche pas car c'est considéré comme le déréférencement d'un (void *). En même temps c'est normal sinon on pourrait faire un "sizeof(f)" qui retournerait la taille de la fonction (ce qui n'a pas vraiment sens...)

Conclusion, c'est un peu le merdier pour les fonctions... Pour le reste, c'est assez claire.
Le C++ apporte beaucoup d'amélioration et même ou sous-ensemble C.

> Et des que tu rajoutes les typedef, les macros et les objets, c'est une horreur sans nom.

Le C++ permet d'éviter les typedef et les macros.

> permer d'analyser et de modifier un programme via un autre programme.

C'est la même horreur que les macros !

[ Répondre ]

> les spécifs de la VM .NET sont normalisée ISOtifié et tout ce que vous voulez.

Pas .NET dans son ensemble (ASP.NET, XAML, etc...). Le C# n'est pas le problème. C'est la plateforme .NET qui pose problème.

[ Répondre ]

> si, il y a bien une question des langages

Oui et non. C'est pas le language qui pose le plus gros problème. Gnome est fait pour supporter tous (ou presque) les languages. Le problème est de reprendre des éléments et/ou spécification de la plateforme .NET ou java pour les mettres dans Gnome et non en surcouche de Gnome (comme c'est le cas de Gnome-java actuellement par exemple).

Les developpeurs de la plateforme Gnome se moquent que tu utilises C# pour faire une appli du moment que le support de C# est une surcouche de Gnome. Par contre supporter la *plateforme* .NET par Gnome, ça ne peut pas se faire en faisant une surcouche. Dans ce cas, .NET doit être au "coeur" de Gnome.

Prenons l'exemple d'XAML. Pour l'intégré dans Gnome, il faut modifier la plateforme Gnome. Que la modification soit faite en C ou en C# ou ... n'est pas le plus important. Par contre si pour avoir le support XAML pour les applis Gnome il faut utiliser des librairies/composants de .NET et/ou risquer d'être attaqué par MS pour des problèmes de brevet, là il y a de gros problèmes.

Le problème est que la plateforme Gnome doit évoluer. Havoc souligne que cette évolution doit rester neutre par rapport aux sociétés commerciales. Si la plateforme Gnome intègre des trucs (spec, API .NET, etc... et quelque soit le language) qui l'emprisonne dans un solution MS (par exemple), alors Ibm, Sun, les contributeurs bénévoles, etc... ne voudrons plus aider Gnome même si celà peut répondre à une demande à court/moyen terme voir même favoriser la diffusion de Gnome.

[ Répondre ]

Pour connaitre les distributions qui ont apporté un fix :
http://lwn.net/Articles/76158/(...)

La page est mise à jour.

[ Répondre ]