> L'intégrité peut etre gérer dans les objets... et les backups, sauvegardes... c'est bien entendu une fonctionnalité des bases de données.
Images ça :
Une base de données accédée en écriture/lecture par un site web, MS-access, SQLform, et une applie spécifique en C. Si tu ajoutes un outil général de consultation de base de donnée pour l'utilisateur il faut moins d'une semaine pour que la base de donnée soit dans un état "anormal" et au bout d'un mois tout doit être refait.
Si c'est la base de donnée qui gère l'intégrité des données, tu n'as pas ce problème. Si c'est l'appli, alors il faut une seul appli sinon c'est rapidement le bordel. On arrive à ton paradoxe :
- les bases de données doivent être interchangable (c'est un problème de standard et pas de postgresql qui respecte les standards (plus que mysql)).
- en reportant l'intégrité des données dans l'applis, tu limites le nombre d'appli utilisatable pour les mêmes données.
> je pense d'ailleurs que la base de données ne devrait servir qu'à stocker des données ;)
C'est une erreur. Les bases de données doivent ne gérer que les données. Ce qui est un peu plus que d'uniquement les stocker. Assurer l'intégrité des données (intégrité référencielle, backup à chaud, etc) c'est un travaille aussi important que de "seulement" stocker les données.
Ce changelog n'est pas dans les sources.
De plus il faut maintenant regarder les sources...
Avant ce n'était pas nécessaire car il n'y avait que le noyau officiel qui n'utilisait pas EXTRAVERSION.
C'est "EXTRAVERSION = .1". Rien de nouveau. Tous les distributeurs utilisent ce champ. Par contre c'est la première fois que Linus l'utilise. Les autres développeurs utilisent ce champs (-ac, -mm, etc...).
Pourquoi ne pas avoir appelé ce noyau 2.6.9 ? Mistère...
> [admin@linux-entreprise-server essai]$ make
> cd . && /bin/sh /home/admin/essai/missing --run autoconf
Normalement le programme missing ne doit pas être excécuté sur la machine cible. Fais tourné missing (./missing ou /usr/share/automake-*/missing sur la bécane de développement en premier (ici FC2)).
Consider these memory requirements for Fedora Core 2, as specified by Red Hat: Minimum for graphical: 192MB and Recommended for graphical: 256MB Does that sound any alarm bells with you? 192MB minimum?
C'est faut ou pas ?
Debian ou Slackware vont peut-être indiquer 128 Mo "recommended" en graphique mais on sait tous que c'est faut. Aucune distribution n'est satisfesante avec 128 Mo en usage bureautique. A moins d'utiliser twm, dilo, balsa, lyx etc. La différence n'est pas dans la distribution mais dans les programmes qu'on utilisent.
> il est tout à fait possible que cela soit effectivement le cas auquel cas l'abandon de XFree86
Pas seulement. X.org a été créé quelques semaines avant la licence 1.1 de XFree86 et X Server (initialement Xwin) presque un an avant.
> Le problème est que je n'ai pas lu d'affirmation définitive sur le sujet et que donc, je ne peux reprocher à certains d'attendre que le débat soit clos.
google est ton ami.
> je me demande honnêtement ce que cache la vitesse avec laquelle les distributions majeures ont changé de fusil d'épaule.
Les mainteneurs XFree de plusieurs distributions majeurs avaient déjà "menacés" XFree86 de faire un fork il y a un an. Le retournement de veste, j'aimerai que tu nous l'explique.
> Parce qu'il n'a pas voulu changer une base majeure de son système avant que les acteurs du libre se mettent d'accord sur cette histoire d'incompatibilité?
http://freedesktop.org/pipermail/x-packagers/2004-February/000004.h(...)
RedHat le 16/02 : Richard Stallman of the Free Software Foundation has expressed
his concerns publically about the new XFree86 license and it's
incompatibility with the GPL. Many others in the community
object strongly to the new license as well.
Branden Robinson of the Debian project has put together a list of
license related issues contained in XFree86's source tree, and
efforts are underway to remove code which is considered to be
non-open source, or under too restrictive of license terms.
(...)
The details are
not yet completely decided, however one thing that is decided, is
that the XFree86 license version 1.1 is unacceptable.
(...)
X11 has sorely lacked such an open and collaborative development
environment for a very long time. It's now time for the open
source community to unite and work together on solving this
problem together, and give X11 permanently back to the community!
Je ne comprend pas cette rumeur de la soit-disant compatibilité avec la GPL de la licence 1.1. Tu peux nous expliquer ?
Et j'aimerais aussi que nous explique comment Slackware a fait pour ignorer ce problème de licence. Histoire d'élever le débat :-)
> S'il vous plait, messieurs ardant supporters de RedHat/FC, mettez de coté vos frustrations
La frustration n'est pas de ce côté. À ignorer ou à minimiser l'actualité des autres grandes distributions et à rapporter (en première page) les faits et gestes anecdotiques de telle ou telle distribution vous prouvez votre fustration.
Vous vous bercez dans l'illusion que ces "petits trucs" font la pluie ou le beau temps.
> essayer d'élever le débat.
Élever le débat, ce serait déjà de constater que cette news n'est que la conséquence qu'un gros travail en amont des distributeurs qui ont clairement refusés la licence 1.1 de XFree86. C'est-à-dire Debian, Gentoo, SuSE, RedHat. Slackware n'y est pour RIEN-DU-TOUT. Ni Mandrake qui jusqu'à maintenant n'a en rien participé à X.org. Je dis ça rapport au lien qui semble là uniquement pour citer Mandrake et compenser votre frustration face à l'inaction totalement de Mandrake jusqu'à maintenant. S'il y a X.org planqué dans un coin d'un ftp de Mandrake ce n'est pas grace à Mandrake mais suite à une initiative personnelle et pas d'un employé de Mandrake.
Si un jour XFree86 retourne à la Licence 1.0 il y aura sûrement un lien vers une obscure actualité de Mandrake pour sous-entendre que c'est aussi grace à Mandrake. C'est dire comme vous êtes frustré.
De plus les distributeurs, ne sont qu'une partie visible. freedesktop a "oublié" XFree86 depuis longtemps. X.org a été créé le 22 janvier et on est début juin !
Qu'on m'explique en quoi le passage de XFree86 à X.org par Slack à la moindre conséquence ?
J'attend des réponses nombreuses...
Élever le débat ce serait souligner l'inconséquence de Slackware qui distribue XFree86 4.4 alors que la FSF a condanné la Licence 1.1 d'XFree. Et ceci au risque violer la GPL. Je dis "rique" car il faudrait vérifier fichier par fichier...
Voilà une news qui méritait la première page. Maintenant que je vois cette news, je regrette de ne pas l'avoir faite.
C'est quand même incroyable que cette news soit en première page.
La news avec Fedora Core 2 Test 2 qui passait a X.org est passée en seconde page alors que c'était les premiers a proposer des paquets pour X.org et a utiliser X.org et ceci il y a plus deux mois !
Autre fait "incroyable", c'est de mettre une référence à "Mandrake sans XFree86" alors qu'actuellement Fedora Core 2 est la seule distribtion non beta a utiliser X.org.
Pour être juste, il faudrait aussi mettre un lien :
- SuSE sans XFree86 4.4
- Debian sans XFree86 4.4
....
> Je fais confiance aux distributeurs pour estimer si un noyau récent peut-être utilisé sur un système critique.
Il y a des gens qui prennent un 2.6.6 sorti la veille le compile sans connaitres toutes les options et sans lire le changelog pour constater que ça marche pas.
Pour être à peu près sûre d'un noyau, il faut passer par un distributeur. Le distributeur connait les bonnes options, est abonnée à la mailing liste Linux, à des développeurs. Il va prendre un Linux vanilla, le laisser mariner quelques semaines et appliquer les corrections les plus importantes avant de le libérer pour satisfaire le plus de monde possible.
Les développeurs Linux développent (ça tombe bien), les distributeurs packagent (ça tombe bien).
> Fedora n'a pas le niveau d'une distrib grand public comme Mandrake
C'est pas une question de niveau. C'est un problème de positionnement.
Pour RedHat faire une distribution type "desktop" ça ne doit pas être très long :
- ajouter flash, java, xine, mp3.
- Peut-être ajouter une interface graphique à yum ou refaire system-config-package (prévu pour FC3).
Et voilà.
C'est ridicule comme boulot. N'oublions pas que RedHat bosse beaucoup sur Gnome donc ils ont les compétences.
De plus c'est surtout lié au fait que Fedora doit être basé sur du libre et RedHat doit éviter les problèmes de DMCA et brevets.
Par contre, Mandrake supporte plus de matériel. Et là c'est un avantage plus que significatif. On peut demander à quelqu'un d'utiliser yum pour s'adapter à Fedora. Par contre patcher le noyau, le configurer, le compiler et l'installaler pour avoir ce @!^# de driver est innenvisagable pour le "grand public".
Bizarre le torrent sur slashdot marche bien ici.
Apparament l'effet slashdot est dévastateur... Mais bittorrent n'y résiste pas.
Je vais néanmoins switcher sur le nouveau torrent.
Tu peux aussi définir ServerName comme indiqué ailleur.
Ou utiliser "UseCanonicalName Off" : # UseCanonicalName: Determines how Apache constructs self-referencing
# URLs and the SERVER_NAME and SERVER_PORT variables.
# When set "Off", Apache will use the Hostname and Port supplied
# by the client. When set "On", Apache will use the value of the
# ServerName directive.
#
UseCanonicalName Off
[^] # Re: Et mysql
Posté par Ayrton . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 1.
Images ça :
Une base de données accédée en écriture/lecture par un site web, MS-access, SQLform, et une applie spécifique en C. Si tu ajoutes un outil général de consultation de base de donnée pour l'utilisateur il faut moins d'une semaine pour que la base de donnée soit dans un état "anormal" et au bout d'un mois tout doit être refait.
Si c'est la base de donnée qui gère l'intégrité des données, tu n'as pas ce problème. Si c'est l'appli, alors il faut une seul appli sinon c'est rapidement le bordel. On arrive à ton paradoxe :
- les bases de données doivent être interchangable (c'est un problème de standard et pas de postgresql qui respecte les standards (plus que mysql)).
- en reportant l'intégrité des données dans l'applis, tu limites le nombre d'appli utilisatable pour les mêmes données.
Bizarre ton raisonnement.
[^] # Re: Et mysql
Posté par Ayrton . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 7.
C'est une erreur. Les bases de données doivent ne gérer que les données. Ce qui est un peu plus que d'uniquement les stocker. Assurer l'intégrité des données (intégrité référencielle, backup à chaud, etc) c'est un travaille aussi important que de "seulement" stocker les données.
[^] # Re: !
Posté par Ayrton . En réponse au journal Linux 2.6.8.1 (ouf) sorti. Évalué à 1.
De plus il faut maintenant regarder les sources...
Avant ce n'était pas nécessaire car il n'y avait que le noyau officiel qui n'utilisait pas EXTRAVERSION.
[^] # Re: !
Posté par Ayrton . En réponse au journal Linux 2.6.8.1 (ouf) sorti. Évalué à 2.
Avant a.b.c était un Linux officiel et un a.b.c{n_importe_quoi_apres} n'était pas un Linux officiel.
Maintenant, on ne sait pas.
Le 2.6.8 restera pour le noyau le moins utilisé. C'est tout.
[^] # Re: !
Posté par Ayrton . En réponse au journal Linux 2.6.8.1 (ouf) sorti. Évalué à 2.
Pourquoi ne pas avoir appelé ce noyau 2.6.9 ? Mistère...
[^] # Re: Humm
Posté par Ayrton . En réponse au message problème de compilation entre fedora et Red Hat ES 3. Évalué à 2.
> [admin@linux-entreprise-server essai]$ make
> cd . && /bin/sh /home/admin/essai/missing --run autoconf
Normalement le programme missing ne doit pas être excécuté sur la machine cible. Fais tourné missing (./missing ou /usr/share/automake-*/missing sur la bécane de développement en premier (ici FC2)).
NB : je ne suis pas un spécialiste de autoconf.
[^] # Re: Ca me rappelle OpenBSD ...
Posté par Ayrton . En réponse au journal PCs carrefour avec Mandrakelinux -SUITE-. Évalué à 1.
# Humm
Posté par Ayrton . En réponse au message problème de compilation entre fedora et Red Hat ES 3. Évalué à 1.
Normalement "./configure" doit marché (s'il est généré sous FC2).
Que te donnes la sortie de "./configure" (généré sous FC2) excécuté sous RHEL .
# 256 Mo recommended
Posté par Ayrton . En réponse au journal Linux est il gros et gras ?. Évalué à 1.
C'est faut ou pas ?
Debian ou Slackware vont peut-être indiquer 128 Mo "recommended" en graphique mais on sait tous que c'est faut. Aucune distribution n'est satisfesante avec 128 Mo en usage bureautique. A moins d'utiliser twm, dilo, balsa, lyx etc. La différence n'est pas dans la distribution mais dans les programmes qu'on utilisent.
# résolution
Posté par Ayrton . En réponse au journal problème de résolution. Évalué à 3.
[^] # Re: Première page ?
Posté par Ayrton . En réponse à la dépêche XFree86 a de moins en moins la côte. Évalué à 2.
http://www.xfree86.org/pipermail/forum/2004-February/003974.html(...)
> En ce qui me concerne, je n'en sais rien
Et bien voilà qui élève le débat...
> il est tout à fait possible que cela soit effectivement le cas auquel cas l'abandon de XFree86
Pas seulement. X.org a été créé quelques semaines avant la licence 1.1 de XFree86 et X Server (initialement Xwin) presque un an avant.
> Le problème est que je n'ai pas lu d'affirmation définitive sur le sujet et que donc, je ne peux reprocher à certains d'attendre que le débat soit clos.
google est ton ami.
> je me demande honnêtement ce que cache la vitesse avec laquelle les distributions majeures ont changé de fusil d'épaule.
Les mainteneurs XFree de plusieurs distributions majeurs avaient déjà "menacés" XFree86 de faire un fork il y a un an. Le retournement de veste, j'aimerai que tu nous l'explique.
> Parce qu'il n'a pas voulu changer une base majeure de son système avant que les acteurs du libre se mettent d'accord sur cette histoire d'incompatibilité?
les "acteurs du libre" étaient d'accord très tôt (avant 4.4rc2) :
http://freedesktop.org/pipermail/x-packagers/2004-February/000003.h(...)
Debian le 16/02 :
Debian will not ship anything with the 1.1 license, full stop.
http://freedesktop.org/pipermail/x-packagers/2004-February/000008.h(...)
SuSE le 20/02 :
SuSE won't ship XFree86 4.4.0 under its current license as well.
http://freedesktop.org/pipermail/x-packagers/2004-February/000004.h(...)
RedHat le 16/02 :
Richard Stallman of the Free Software Foundation has expressed
his concerns publically about the new XFree86 license and it's
incompatibility with the GPL. Many others in the community
object strongly to the new license as well.
Branden Robinson of the Debian project has put together a list of
license related issues contained in XFree86's source tree, and
efforts are underway to remove code which is considered to be
non-open source, or under too restrictive of license terms.
(...)
The details are
not yet completely decided, however one thing that is decided, is
that the XFree86 license version 1.1 is unacceptable.
(...)
X11 has sorely lacked such an open and collaborative development
environment for a very long time. It's now time for the open
source community to unite and work together on solving this
problem together, and give X11 permanently back to the community!
Je ne comprend pas cette rumeur de la soit-disant compatibilité avec la GPL de la licence 1.1. Tu peux nous expliquer ?
Et j'aimerais aussi que nous explique comment Slackware a fait pour ignorer ce problème de licence. Histoire d'élever le débat :-)
[^] # Re: Première page ?
Posté par Ayrton . En réponse à la dépêche XFree86 a de moins en moins la côte. Évalué à -2.
Pour qui, quoi ?
Pour XFree ?
Je ne vois pas le "tournant" pour XFree puisque "On parle d'XFree ici".
[^] # Re: Première page ?
Posté par Ayrton . En réponse à la dépêche XFree86 a de moins en moins la côte. Évalué à -2.
La frustration n'est pas de ce côté. À ignorer ou à minimiser l'actualité des autres grandes distributions et à rapporter (en première page) les faits et gestes anecdotiques de telle ou telle distribution vous prouvez votre fustration.
Vous vous bercez dans l'illusion que ces "petits trucs" font la pluie ou le beau temps.
> essayer d'élever le débat.
Élever le débat, ce serait déjà de constater que cette news n'est que la conséquence qu'un gros travail en amont des distributeurs qui ont clairement refusés la licence 1.1 de XFree86. C'est-à-dire Debian, Gentoo, SuSE, RedHat. Slackware n'y est pour RIEN-DU-TOUT. Ni Mandrake qui jusqu'à maintenant n'a en rien participé à X.org. Je dis ça rapport au lien qui semble là uniquement pour citer Mandrake et compenser votre frustration face à l'inaction totalement de Mandrake jusqu'à maintenant. S'il y a X.org planqué dans un coin d'un ftp de Mandrake ce n'est pas grace à Mandrake mais suite à une initiative personnelle et pas d'un employé de Mandrake.
Si un jour XFree86 retourne à la Licence 1.0 il y aura sûrement un lien vers une obscure actualité de Mandrake pour sous-entendre que c'est aussi grace à Mandrake. C'est dire comme vous êtes frustré.
De plus les distributeurs, ne sont qu'une partie visible. freedesktop a "oublié" XFree86 depuis longtemps. X.org a été créé le 22 janvier et on est début juin !
Qu'on m'explique en quoi le passage de XFree86 à X.org par Slack à la moindre conséquence ?
J'attend des réponses nombreuses...
Élever le débat ce serait souligner l'inconséquence de Slackware qui distribue XFree86 4.4 alors que la FSF a condanné la Licence 1.1 d'XFree. Et ceci au risque violer la GPL. Je dis "rique" car il faudrait vérifier fichier par fichier...
Voilà une news qui méritait la première page. Maintenant que je vois cette news, je regrette de ne pas l'avoir faite.
# Première page ?
Posté par Ayrton . En réponse à la dépêche XFree86 a de moins en moins la côte. Évalué à -5.
La news avec Fedora Core 2 Test 2 qui passait a X.org est passée en seconde page alors que c'était les premiers a proposer des paquets pour X.org et a utiliser X.org et ceci il y a plus deux mois !
Autre fait "incroyable", c'est de mettre une référence à "Mandrake sans XFree86" alors qu'actuellement Fedora Core 2 est la seule distribtion non beta a utiliser X.org.
Pour être juste, il faudrait aussi mettre un lien :
- SuSE sans XFree86 4.4
- Debian sans XFree86 4.4
....
Une tempête dans un verre d'eau...
[^] # Re: Mise à jour de leur site !
Posté par Ayrton . En réponse au journal XFree86 a de moins en moins la cote. Évalué à -3.
Qu'on ne fait pas d'omelette dans casser des eoufs ?
[^] # Re: Toujours la même histoire...
Posté par Ayrton . En réponse au journal Kernel 2.6, 6 mois après. Évalué à 4.
Il y a des gens qui prennent un 2.6.6 sorti la veille le compile sans connaitres toutes les options et sans lire le changelog pour constater que ça marche pas.
Pour être à peu près sûre d'un noyau, il faut passer par un distributeur. Le distributeur connait les bonnes options, est abonnée à la mailing liste Linux, à des développeurs. Il va prendre un Linux vanilla, le laisser mariner quelques semaines et appliquer les corrections les plus importantes avant de le libérer pour satisfaire le plus de monde possible.
Les développeurs Linux développent (ça tombe bien), les distributeurs packagent (ça tombe bien).
[^] # Re: Un petit lien ?
Posté par Ayrton . En réponse à la dépêche Fedora Core 2 (Tettnang) pour i386 et AMD64. Évalué à 2.
http://home.gagme.com/greg/linux/fc2-tips.php(...)
# Fedora News Updates #12
Posté par Ayrton . En réponse à la dépêche Fedora Core 2 (Tettnang) pour i386 et AMD64. Évalué à 1.
http://fedoranews.org/colin/fnu/issue12.shtml(...)
Un "must read" pour tout ceux qui utilisent Fedora Core 2.
# Test FC2
Posté par Ayrton . En réponse à la dépêche Fedora Core 2 (Tettnang) pour i386 et AMD64. Évalué à 2.
Un classique :
- pas de mp3
- pas de flash
- etc...
Encore un testeur qui ne sait pas ce qu'il teste.
[^] # Re: mon avis
Posté par Ayrton . En réponse à la dépêche Fedora Core 2 (Tettnang) pour i386 et AMD64. Évalué à -3.
Oui. Mais FC2 est déjà intéressante.
> je trouve que l'install est magnifique
Tu montres que tu ne connaissais pas rh/fedora :-)
[^] # Re: Trop de news sur Fedora ?
Posté par Ayrton . En réponse au journal Nouveau torrent pour Fedora Core 2. Évalué à 1.
C'est pas une question de niveau. C'est un problème de positionnement.
Pour RedHat faire une distribution type "desktop" ça ne doit pas être très long :
- ajouter flash, java, xine, mp3.
- Peut-être ajouter une interface graphique à yum ou refaire system-config-package (prévu pour FC3).
Et voilà.
C'est ridicule comme boulot. N'oublions pas que RedHat bosse beaucoup sur Gnome donc ils ont les compétences.
De plus c'est surtout lié au fait que Fedora doit être basé sur du libre et RedHat doit éviter les problèmes de DMCA et brevets.
Par contre, Mandrake supporte plus de matériel. Et là c'est un avantage plus que significatif. On peut demander à quelqu'un d'utiliser yum pour s'adapter à Fedora. Par contre patcher le noyau, le configurer, le compiler et l'installaler pour avoir ce @!^# de driver est innenvisagable pour le "grand public".
# > 2 membres du projet Debian tués :(
Posté par Ayrton . En réponse au journal 2 membres du projet Debian tués :(. Évalué à 2.
Paix à leurs âmes, pensées aux familles.
Restez prudent.
[^] # Re: ça marche ici
Posté par Ayrton . En réponse au journal Nouveau torrent pour Fedora Core 2. Évalué à 1.
Le problème c'est que le nouveau torrent ne tient pas compte des "morceaux" d'iso déjà downloadés.
Bon ben... j'attend demain le torrent officiel. On est pas à une journée près.
# ça marche ici
Posté par Ayrton . En réponse au journal Nouveau torrent pour Fedora Core 2. Évalué à 1.
Apparament l'effet slashdot est dévastateur... Mais bittorrent n'y résiste pas.
Je vais néanmoins switcher sur le nouveau torrent.
[^] # Re: redirection.
Posté par Ayrton . En réponse au journal Mailman, c'est quand même relativement foireux.... Évalué à 2.
Le fonctionnement de rewriterule est assez suptile et pas toujous facile à débugger.
Là j'ai pas d'idée.
> avec le R, ça marche mais mon listes.agora.eu.org est renommé en ns30318.ovh.net
Tu peux aussi :
RewriteRule ^/$ http://listes.agora.eu.org/listinfo(...) [L,R]
Tu peux aussi définir ServerName comme indiqué ailleur.
Ou utiliser "UseCanonicalName Off" :
# UseCanonicalName: Determines how Apache constructs self-referencing
# URLs and the SERVER_NAME and SERVER_PORT variables.
# When set "Off", Apache will use the Hostname and Port supplied
# by the client. When set "On", Apache will use the value of the
# ServerName directive.
#
UseCanonicalName Off
C'est ma solution préférée.