Pour info, FC6 sort la semaine prochaine. Il est peut-être urgent d'attendre.
Toujours pour info, la mise à jour d'une release de fedora à une autre via yum n'est pas supporté. Si ça marche tant mieux, si ça ne marche tant pis.
Par expérience, je fais toujours une installation "fraiche".
T'es sûr d'avoir fait ça et dans cet ordre ? :
* changer /etc/yum.repo.d pour pointer sur FC5
* yum clean all
* yum install kernel
* yum remove kernel-2.6.14*
* rpm -Uvh fedora-release-5-5.noarch.rpm
* yum update
* /sbin/fixfiles relabel
Que te donne la commande :
$ rpm -q -a | grep kernel
> - La glibc 2.4 n'est pas utilisable avec un noyau 2.4 standart
??
C'est uniquement car il manque linuxthread ?
> - gcc ne permettait pas de compiler toutes les applications possibles il y a encore quelques mois.
gcc 4 était utilisé par FC4 (pour compiler toute la distribution + extra). FC4 est sorti il y a plus d'un an et demi !
Pour FC6 (qui a quelques paquet de plus que FC4) ça fait 3320 src.rpm et 5700 (i386|noarch).rpm. C'est grosso-modo la même chose pour FC4.
Donc les applis qui ne compilent pas avec gcc 4 doivent être très rare et très fort probablement non livré par Slackware. A moins que Slack utilise des programmes si vieux qu'ils nécessitent un vieux gcc...
> - Apache 1.x est extrèmement populaire et il a prouvé sa robustesse.
Apache 2.0.40 (2.0.36 était estimé stable) est sorti il y a plus de 4 ans ! Il était dans RH 8.0. Dans RHEL (pour entreprise et serveurs critiques) c'est utilisé depuis 3 ans !
> Tout comme pour le noyau, il attend que celui fasse ses preuves avant de faire le "grand saut".
Noyau 2.6 pour RHEL 4 (pour entreprise et serveurs critiques) sorti il y a plus d'an. Idem pour Novell/SuSE.
> La stabilité est primordiale pour Slackware.
Excuse bidon. C'est plus de la stabilité, c'est de l'immobilisme.
> Tant qu'une nouvelle branche de Linux ne sera pas ouverte, il sera difficile ou éphémère, pour une petite équipe, de distribuer un système stable, basé sur un Linux 2.6.
La branche 2.6 est *aussi* une branche de développement (d'où la non existance de branche 2.7). C'est un changement de direction de Linus avec l'accord de la majorité des développeurs et notament des "grosses" distributions (Red Hat et Novell). C'est un changement qui n'a pas été remis en cause.
Je trouve normal que Linus soit plus préoccupé par les contributeurs que par le mainteneur de slackware.
> En 3 ans et demi, udev en est à sa 101ème version, soit une nouvelle version tous les 12 jours en moyenne.
Udev n'a pas atteint la version 1.0. Donc, ça change. Notes que le trio (voire le quatuor avec Linux) udev/dbus/hal n'a pas atteint la version 1.0. Donc je ne comprend pas pourquoi tu gueules. Tu gueules seulement car c'est dans les autres distributions et pas dans Slack. Il n'y a pas d'API de figé. Et c'est normal, c'est encore en plein développement. Ces trois projets forme un tout et répond à la problématique des nombreux type de périphériques amovibles.
Alors deux choix :
1- on fige l'API et on a un truc qui suck
2- on ne fige pas l'API jusqu'à ce qu'on ait atteint un truc qui roxe
C'est l'option (2) qui a été choisi, sinon ça prendrait des années pour avoir un truc qui roxe.
L'option (1) a les problèmes suivant :
- il faut maintenir deux branches : une stable et une de développement
- la branche de développement est peu testée et potentielle non utilisable (donc peu de testeur)
- les distributeurs ne développent pas sur la branche de développement car ce n'est pas directement utilisable dans leur prochaine version
- les distributeurs finissent par faire des "mini-fork" par rapport à la branche stable. "mini-fork" souvent incompatible entre distributions. Ces développements ne sont pas consolidés en upstream.
L'option (2) a les problèmes suivant :
- pas facile pour les petites structures.
Je préfère de loin l'option (2) et tant pis pour Slackware qui ne contribue pas à Linux ni à udev/etc. Désolé.
Il est normal que Linux/udev/etc prêtent peu d'attention à ceux qui ne contribuent pas.
> J'éspère qu'ils vont simplement ne plus le mettre par défaut mais toujours le proposer... (contrairement à plusieurs distribution (FC par example) qui ne le propose même pas
Si, c'est proposé. Lors de l'installation il faut faire "linux reiser" "linux xfs" "linux etc".
Fedora propose tous les systèmes de fichier qui sont upstreams.
Si t'avais utilisé FC, tu aurais vu qu'il y a reiserfs-utils, etc...
Par contre, Fedora ne supporte QUE ext3. Inutile de faire un rapport de bug sur reiserfs, il sera foutu à la poubelle dans la seconde. Mais il est difficile de reprocher ça Fedora vu que les autres ne supportent RIEN ! Sauf SuSE qui supporte reiserfs mais va arrêter.
Le fait que l'installation pour reiser ne soit pas proposé de façon visible, est que de Fedora découle RHEL et dans RHEL il n'y a que ext3 qui est supporté (avec des clients payants qui donc peuvent légitimement gueuler si ça merde).
Pour RHEL 5, c'est "pire" (NB : ça avait été annoncé par Red Hat depuis RHEL 3), il n'y a pas que les modules ext3.
> (qui propose pas grand chose d'ailleurs, et c'est bien dommage)
FUD detected : http://fedoraproject.org/wiki/Overview
C'est dans Fedora qu'à été développé AIGLX, c'est dans Fedora qu'il y a SeLinux pas défaut, c'est dans Fedora qu'il y a GFS, c'est Fedora qui va utiliser en premier libvirt pour du Xen "out of the box", etc, etc...
Tient, glibc 2.5 vient de tomber dans rawhide. => donc dans FC6.
> Ce n'est pas un problème de 1 ou 2 serveurs. De toute manière, si tu veux avoir une machine en failover, il t'en faudra toujours 2.
Le "problème" est d'en avoir deux qui tournent en permanence alors que dans 99,9 % des cas un seul suffit.
Si t'as un parc de 10 serveurs, tu peux prévoir 2 bécanes en cas de pénin. Avec Slony-1, il en faut 10.
Il est vrai qu'on peut aussi arranger la "redondance" : serveur A fait backup (failover) pour le serveur B et vice versa. Ça ajoute aussi des contraintes.
Slony-1, pg_(dump|restore) et WAL ont tous leurs intérêts/défauts.
Faut arrêter les délires anti-commercial.
Les Novell/Red Hat/Intel/IBM (et un peu Mandriva) contribuent énormement au libre et ça finit dans ta distribution.
Tu ne veux pas de leurs contributions ?
Tu veux que le logiciel libre ne soit pas que par des personnes non payées au fond de leur garage ?
> Et puis pour les paquetages rpm, c'est le "r" de redhat qui m'offusque.
Réflexion d'une stupidité sans limité. En fait, il n'y a aucun réflexion.
RPM veut dire "Rpm Package Manageur". Ça a changé il y a plusieurs années.
Puis rpm est considéré comme non maintenu actuellement. Red Hat/Fedora, Novell et Mandriva regarde pour forker le projet.
> Linux c'est avant tout un Noyau développé par Torvald et ses potes
Linux c'est maintenant 98 % des contributions qui viennent de développeurs payés par des boîtes commerciales (dexit Andrew Morton).
Tu devrais installer Linux 1.2 pour respecter tes opinions.
Quel java ? Celui de Sun ?
Effectivement il n'est pas libre.
Celui dans gcj/etc ?
Ils sont libres.
Pour indication, gcj/etc est dans par Fedora Core et RHEL (et sûrement beaucoup d'autre). Or le responsable juridique de Fedora Core et RHEL est Red Hat ! Ce dernier est le concurrent le plus sérieux de Solaris (Red Hat pique plein de clients à Solaris).
Afin après l'achat de JBoss par Red Hat, Red Hat commence à se faire pas mal de pognon avec java : http://www.redhat.com/about/news/prarchive/2006/earnings_200(...) :
JBoss-related revenue of $7 million
S'il y avait le moindre problème avec gcj/etc :
- Red Hat retirerait gcj/etc.
- Sun attaquerait Red Hat
C'est la méthode standard.
Le problème est qu'elle consomme beaucoup de ressource et n'est pas incrémentale. Néanmoins elle est indispensable (au moins pour les mises à jours de postgresql).
Une autre méthode est la réplication avec slony-1. Mais dans ce cas il faut deux serveurs.
Sauf que là il n'y a aucun argument. Ce sont des affirmations gratuites.
> Additionally, MySQL is much faster database and has better performance than PostgreSQL. That's why MySQL is more popular than its competitor.
C'est faux. Ce qui a fait la popularité de Mysql :
- Les hébergeurs de site prenaient Mysl. Normal mysql était adapté à l'utilisation des quota du FS contrairement à PostgreSQL. PostgreSQL a corrigé ça.
- Mysql trouvait sur Windows. Postgresql tourne maintenant aussi sous Windows.
> However I've never seen data loss with MySQL even with often power-offs
Alors c'est bien rigolo. Mysql ne fait pas de fsync à la fin de transaction/modification. Au contraire PostgreSQL fait un fsync. Un confirmation de modification par postgresql se fait TOUJOURS après un fsync.
Si postgresql te dit "les données sont enregistrés sur disque", alors ils sont enregistrés sur le disque.
Si mysql te dit "les données sont enregistrés sur le disque", alors il faut comprendre qu'ils sont peut-être enregistrés sur le disque.
Et ce n'est même un bug temporaire. C'est un choix que fait Mysql pour être plus rapide. Tu vas dire que c'est une "feature".
C'est principalement pour cette raison que Mysql est plus rapide que postgresql. Mais dès qu'on monte en charge, l'avantage s'estompe car pendant l'attente d'un fsync postgresql a aussi autre chose à faire.
On le sait que Mysql ne supporte pas les test acid, je peux aussi t'affirmer qu'il ne supporte pas les coupures de courant.
Pour info, j'ai eu partiquement aucune difficulté pour faire tourner doclear 2 sous free. Les seuls pépins étaient évidents à corriger et c'étaient des problèmes de configuration.
La doc aussi est un bijou. Un grand bravo pour ce travail.
Postgresql est un bijou et pas plus compliqué à utiliser que mysql. D'ailleurs il est souvent plus simple d'utiliser postgresql que de se prendre la tête à contourner les limitations de mysql.
Il y a peut-être la configuration (!= utilisation) qui est plus compliqué. Mais ici la configuration est faite par free.
> quoique j'ai cru comprendre que mysql avait d'énormes progrès de ce côté
Je dois reconnaitre que je fuis mysql depuis plusieures années maintenant. Je l'ai utilisé jusqu'à la version 3.54 (?). Je n'ai pas regardé les versions suivantes (V4 et V5). Même pour des petits projets je préfère postresql.
> MySQL est "un poil" plus rapide,
Ça dépend. Pour les benchs probablement. Mais le manque de fonctionnalité de Mysql fait que tu donnes plus de boulot à php par exemple.
Faire un insert "brut" sous Mysql est plus rapide. Mais avec postgresql (et bien utilisé) tu fais l'insert et tous les contrôles (+requêtes annexes) sont faits. Avec mysql il faut locker les tables (donc la base est indisponible pour les autres), faires des requêtes pour voir si les nouvelles données sont ok, puis faire l'insert. Et ne parlons pas de problème compliqué avec transaction sur plusieurs tables. Au final (somme php+mysql), je doute que mysql donne un gain en performance .
Tu t'y prend à l'envers. Tu regardes ce qui se fait aujoud'hui, alors que tu devrais te demander ce qui se fera demain. Html 3 c'était bien à l'époque.
Un grand messieur à dit que 640 Ko était suffisant. Vu ce qui se faisait à l'époque, il avait raison.
Toi tu dis la même chose mais avec mysql.
Un autre a dit vers les débuts de Linux que le multitache ne sert à rien pour une station de travail ! A l'époque il avait aussi raison.
Tu veux revenir au systèmes monotaches avec 640 Ko ?
> Mais je n'arrive pas a voir quelles applications web auraient besoin d'un vrai SGBD
Il y a plein de code php/perl/etc qui font des trucs que DEVRAIENT faire le SGDB. Il le font car mysql ne sait pas le faire. Requêtes imbriquée, transaction, contrôle d'intégrité, rêgles, convertion de type de données, etc...
> un simple MySQL, qui, étant plus simple, est censé etre plus rapide.
Linux 1.2 est plus simple que Linux 2.6. Tu crois que Linux 1.2 est plus rapide que Linux 2.6 ?
Si avec postgresql tu fais exactement la même chose qu'avec mysql, il n'y a aucun intérêt à passer à postgresql.
Par contre postgresql à des fonctionnalité que n'a pas mysql (voir la doc). En plus il est mieux foutu (la gestion des dates sous mysql est à s'arracher les cheveux).
C'est vrai qu'un mec qui ne connais que mysql, qui crois qu'un SGBD ne peut faire que ce que fait mysql peut penser que postgresql ne sert à rien.
> je m'interroge sur son utilité pour les pages perso de Free.
Avec free tu as déjà 1 Go d'espace !
Et plus, il y a une option pour 10 Go d'espace !
Ça donne des idées.
[^] # Re: Re:
Posté par clearstream . En réponse au message Mise à jour FC4 -> FC5. Évalué à 1.
Toujours pour info, la mise à jour d'une release de fedora à une autre via yum n'est pas supporté. Si ça marche tant mieux, si ça ne marche tant pis.
Par expérience, je fais toujours une installation "fraiche".
# Re:
Posté par clearstream . En réponse au message Mise à jour FC4 -> FC5. Évalué à 1.
* changer /etc/yum.repo.d pour pointer sur FC5
* yum clean all
* yum install kernel
* yum remove kernel-2.6.14*
* rpm -Uvh fedora-release-5-5.noarch.rpm
* yum update
* /sbin/fixfiles relabel
Que te donne la commande :
$ rpm -q -a | grep kernel
[^] # Re: Et Slack ?
Posté par clearstream . En réponse au journal OpenSuse et ReiserFS. Évalué à -3.
??
C'est uniquement car il manque linuxthread ?
> - gcc ne permettait pas de compiler toutes les applications possibles il y a encore quelques mois.
gcc 4 était utilisé par FC4 (pour compiler toute la distribution + extra). FC4 est sorti il y a plus d'un an et demi !
Pour FC6 (qui a quelques paquet de plus que FC4) ça fait 3320 src.rpm et 5700 (i386|noarch).rpm. C'est grosso-modo la même chose pour FC4.
Donc les applis qui ne compilent pas avec gcc 4 doivent être très rare et très fort probablement non livré par Slackware. A moins que Slack utilise des programmes si vieux qu'ils nécessitent un vieux gcc...
> - Apache 1.x est extrèmement populaire et il a prouvé sa robustesse.
Apache 2.0.40 (2.0.36 était estimé stable) est sorti il y a plus de 4 ans ! Il était dans RH 8.0. Dans RHEL (pour entreprise et serveurs critiques) c'est utilisé depuis 3 ans !
> Tout comme pour le noyau, il attend que celui fasse ses preuves avant de faire le "grand saut".
Noyau 2.6 pour RHEL 4 (pour entreprise et serveurs critiques) sorti il y a plus d'an. Idem pour Novell/SuSE.
> La stabilité est primordiale pour Slackware.
Excuse bidon. C'est plus de la stabilité, c'est de l'immobilisme.
[^] # Re: Slackware, Debian edition
Posté par clearstream . En réponse à la dépêche Linux Slackware 11.0 est disponible. Évalué à -4.
La branche 2.6 est *aussi* une branche de développement (d'où la non existance de branche 2.7). C'est un changement de direction de Linus avec l'accord de la majorité des développeurs et notament des "grosses" distributions (Red Hat et Novell). C'est un changement qui n'a pas été remis en cause.
Je trouve normal que Linus soit plus préoccupé par les contributeurs que par le mainteneur de slackware.
> En 3 ans et demi, udev en est à sa 101ème version, soit une nouvelle version tous les 12 jours en moyenne.
Udev n'a pas atteint la version 1.0. Donc, ça change. Notes que le trio (voire le quatuor avec Linux) udev/dbus/hal n'a pas atteint la version 1.0. Donc je ne comprend pas pourquoi tu gueules. Tu gueules seulement car c'est dans les autres distributions et pas dans Slack. Il n'y a pas d'API de figé. Et c'est normal, c'est encore en plein développement. Ces trois projets forme un tout et répond à la problématique des nombreux type de périphériques amovibles.
Alors deux choix :
1- on fige l'API et on a un truc qui suck
2- on ne fige pas l'API jusqu'à ce qu'on ait atteint un truc qui roxe
C'est l'option (2) qui a été choisi, sinon ça prendrait des années pour avoir un truc qui roxe.
L'option (1) a les problèmes suivant :
- il faut maintenir deux branches : une stable et une de développement
- la branche de développement est peu testée et potentielle non utilisable (donc peu de testeur)
- les distributeurs ne développent pas sur la branche de développement car ce n'est pas directement utilisable dans leur prochaine version
- les distributeurs finissent par faire des "mini-fork" par rapport à la branche stable. "mini-fork" souvent incompatible entre distributions. Ces développements ne sont pas consolidés en upstream.
L'option (2) a les problèmes suivant :
- pas facile pour les petites structures.
Je préfère de loin l'option (2) et tant pis pour Slackware qui ne contribue pas à Linux ni à udev/etc. Désolé.
Il est normal que Linux/udev/etc prêtent peu d'attention à ceux qui ne contribuent pas.
# Sous RPM
Posté par clearstream . En réponse au message Chmod 777 /. Évalué à 1.
$ rpm -q -l -v -a
[...]
-rw-r--r-- 1 root root 922 sep 10 23:21 /etc/httpd/conf.d/mod_suphp.conf
-rw-r--r-- 1 root root 881 sep 10 23:21 /etc/suphp.conf
-rwxr-xr-x 1 root root 465 sep 29 12:59 /etc/profile.d/kde.csh
-rwxr-xr-x 1 root root 407 sep 29 12:59 /etc/profile.d/kde.sh
drwxrwx--- 2 smmsp smmsp 0 sep 5 15:27 /var/spool/clientmqueue
drwx------ 2 root mail 0 sep 5 15:27 /var/spool/mqueue
drwx------ 2 root root 0 sep 5 14:14 /var/spool/cron
drwx--x--- 2 root lp 0 oct 1 22:24 /var/spool/cups
drwxrwx--T 2 root lp 0 oct 1 22:24 /var/spool/cups/tmp
[...]
Il te reste a faire des petits scripts pour appliquer ça directement.
Il y a aussi --queryformat :
$ rpm -q --queryformat="%{FILEMODES:perms}\t%{FILEMODES}\t%{DIRNAMES}%{NAME}\n" -a
[...]
drwx------ 16832 /etc/pki/openssl
drwxr-xr-x 16877 /usr/share/doc/gnome-audio
-rwxr-xr-x 33261 /sbin/hdparm
-rw-r--r-- 33188 /etc/gnome-mime-data
lrwxrwxrwx 41471 /usr/bin/system-config-network
-rw-r--r-- 33188 /etc/security/console.perms.d/mga_vid-kmod-common
-rwxr-xr-x 33261 /usr/bin/nautilus-sendto
lrwxrwxrwx 41471 /usr/share/mplayer/mplayer-fonts
-rwxr-xr-x 33261 /usr/bin/dos2unix
[...]
Et --dump, , peut-être plus façile à utiliser en script
& rpm -q --dump -a
[...]
/usr/lib/libhal.so 15 1159316129 00000000000000000000000000000000 0120777 root root 0 0 0 libhal.so.1.0.0
/usr/lib/pkgconfig/hal-storage.pc 272 1159316162 a433f064a92ad66e032a693de29cdab1 0100644 root root 0 0 0 X
/usr/lib/pkgconfig/hal.pc 287 1159316162 95a66f9c08cd9268bda4f066edf3346c 0100644 root root 0 0 0 X
[...]
# Ext3 ?
Posté par clearstream . En réponse au message fsck au démarrage ne fonctionne plus. Évalué à 1.
Il faut alors lancer "fsck -f".
Sinon tu peux "jouer" avec tune2fs.
Par exemple :
$ tune2fs -c 20 -C 20 /dev/...
$ reboot
Là, fsck va être "réellement" lancé.
[^] # Re: C'est dommage
Posté par clearstream . En réponse au journal OpenSuse et ReiserFS. Évalué à 2.
Pour que pour des raisons historiques. Aujourd'hui le principe de base de ext2 n'est pas remis en cause. Ext4 sera peut-être compatible ext2.
[^] # Re: C'est dommage
Posté par clearstream . En réponse au journal OpenSuse et ReiserFS. Évalué à 3.
Si, c'est proposé. Lors de l'installation il faut faire "linux reiser" "linux xfs" "linux etc".
Fedora propose tous les systèmes de fichier qui sont upstreams.
Si t'avais utilisé FC, tu aurais vu qu'il y a reiserfs-utils, etc...
Par contre, Fedora ne supporte QUE ext3. Inutile de faire un rapport de bug sur reiserfs, il sera foutu à la poubelle dans la seconde. Mais il est difficile de reprocher ça Fedora vu que les autres ne supportent RIEN ! Sauf SuSE qui supporte reiserfs mais va arrêter.
Le fait que l'installation pour reiser ne soit pas proposé de façon visible, est que de Fedora découle RHEL et dans RHEL il n'y a que ext3 qui est supporté (avec des clients payants qui donc peuvent légitimement gueuler si ça merde).
Pour RHEL 5, c'est "pire" (NB : ça avait été annoncé par Red Hat depuis RHEL 3), il n'y a pas que les modules ext3.
> (qui propose pas grand chose d'ailleurs, et c'est bien dommage)
FUD detected : http://fedoraproject.org/wiki/Overview
C'est dans Fedora qu'à été développé AIGLX, c'est dans Fedora qu'il y a SeLinux pas défaut, c'est dans Fedora qu'il y a GFS, c'est Fedora qui va utiliser en premier libvirt pour du Xen "out of the box", etc, etc...
Tient, glibc 2.5 vient de tomber dans rawhide. => donc dans FC6.
http://fedoraproject.org/wiki/Objectives
[^] # Re: simple... peut-etre pas?
Posté par clearstream . En réponse au message quelle distribution linux pour intel core 2 duo. Évalué à 1.
FC6 aura un noyau 2.6.18 (j'ai une FC6 test 3 avec linux 2.6.18).
Sortie de FC6 le 11 octobre (si tout va bien).
[^] # Re: ç'pas moi
Posté par clearstream . En réponse au journal Le titre de Red Hat s'effondre à Wall Street. Évalué à 0.
[^] # Re: ç'pas moi
Posté par clearstream . En réponse au journal Le titre de Red Hat s'effondre à Wall Street. Évalué à 1.
Au bureau, c'est une bonne idée.
[^] # Re: ç'pas moi
Posté par clearstream . En réponse au journal Le titre de Red Hat s'effondre à Wall Street. Évalué à -1.
Je t'adore. Bisous.
A ce soir.
# FS
Posté par clearstream . En réponse au message Images dans une bdd ou sur le file system ?. Évalué à 1.
Si t'as bien organisé ton site, tu dois pouvoir passer facilement du stockage FS à BDD.
[^] # Re: Bonne nouvelle
Posté par clearstream . En réponse au journal free & postgresql 8 & php 5. Évalué à 1.
Le "problème" est d'en avoir deux qui tournent en permanence alors que dans 99,9 % des cas un seul suffit.
Si t'as un parc de 10 serveurs, tu peux prévoir 2 bécanes en cas de pénin. Avec Slony-1, il en faut 10.
Il est vrai qu'on peut aussi arranger la "redondance" : serveur A fait backup (failover) pour le serveur B et vice versa. Ça ajoute aussi des contraintes.
Slony-1, pg_(dump|restore) et WAL ont tous leurs intérêts/défauts.
[^] # Re: Debian sucks ; Suse win !!
Posté par clearstream . En réponse au message Comparaison entre Debain et Suse. Évalué à 5.
Les Novell/Red Hat/Intel/IBM (et un peu Mandriva) contribuent énormement au libre et ça finit dans ta distribution.
Tu ne veux pas de leurs contributions ?
Tu veux que le logiciel libre ne soit pas que par des personnes non payées au fond de leur garage ?
> Et puis pour les paquetages rpm, c'est le "r" de redhat qui m'offusque.
Réflexion d'une stupidité sans limité. En fait, il n'y a aucun réflexion.
RPM veut dire "Rpm Package Manageur". Ça a changé il y a plusieurs années.
Puis rpm est considéré comme non maintenu actuellement. Red Hat/Fedora, Novell et Mandriva regarde pour forker le projet.
> Linux c'est avant tout un Noyau développé par Torvald et ses potes
Linux c'est maintenant 98 % des contributions qui viennent de développeurs payés par des boîtes commerciales (dexit Andrew Morton).
Tu devrais installer Linux 1.2 pour respecter tes opinions.
[^] # Re: ç'pas moi
Posté par clearstream . En réponse au journal Le titre de Red Hat s'effondre à Wall Street. Évalué à -1.
On t'a grillé la priorité peut-être ?
> chui devenu gentil quoi !
M'enfin, la bourse ça monte et ça descent. Peut-être que cette "news" n'était pas assez féroce à ton gout.
[^] # Re: ç'pas moi
Posté par clearstream . En réponse au journal Le titre de Red Hat s'effondre à Wall Street. Évalué à 0.
# A propos de finance
Posté par clearstream . En réponse au journal Le titre de Red Hat s'effondre à Wall Street. Évalué à 5.
http://www.redhat.com/about/news/prarchive/2006/earnings_200(...)Je ne me fais pas de soucis pour Red Hat ni pour ses actionnaires.
[^] # Re: Bonne nouvelle ?
Posté par clearstream . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 10.
Quel java ? Celui de Sun ?
Effectivement il n'est pas libre.
Celui dans gcj/etc ?
Ils sont libres.
Pour indication, gcj/etc est dans par Fedora Core et RHEL (et sûrement beaucoup d'autre). Or le responsable juridique de Fedora Core et RHEL est Red Hat ! Ce dernier est le concurrent le plus sérieux de Solaris (Red Hat pique plein de clients à Solaris).
Afin après l'achat de JBoss par Red Hat, Red Hat commence à se faire pas mal de pognon avec java :
http://www.redhat.com/about/news/prarchive/2006/earnings_200(...) :
S'il y avait le moindre problème avec gcj/etc :
- Red Hat retirerait gcj/etc.
- Sun attaquerait Red Hat
[^] # Re: Bonne nouvelle
Posté par clearstream . En réponse au journal free & postgresql 8 & php 5. Évalué à 1.
Le problème est qu'elle consomme beaucoup de ressource et n'est pas incrémentale. Néanmoins elle est indispensable (au moins pour les mises à jours de postgresql).
Une autre méthode est la réplication avec slony-1. Mais dans ce cas il faut deux serveurs.
[^] # Re: Bonne nouvelle
Posté par clearstream . En réponse au journal free & postgresql 8 & php 5. Évalué à 2.
>
> http://www.omnistarinc.com/~fonin/devtools.php
Sauf que là il n'y a aucun argument. Ce sont des affirmations gratuites.
> Additionally, MySQL is much faster database and has better performance than PostgreSQL. That's why MySQL is more popular than its competitor.
C'est faux. Ce qui a fait la popularité de Mysql :
- Les hébergeurs de site prenaient Mysl. Normal mysql était adapté à l'utilisation des quota du FS contrairement à PostgreSQL. PostgreSQL a corrigé ça.
- Mysql trouvait sur Windows. Postgresql tourne maintenant aussi sous Windows.
> However I've never seen data loss with MySQL even with often power-offs
Alors c'est bien rigolo. Mysql ne fait pas de fsync à la fin de transaction/modification. Au contraire PostgreSQL fait un fsync. Un confirmation de modification par postgresql se fait TOUJOURS après un fsync.
Si postgresql te dit "les données sont enregistrés sur disque", alors ils sont enregistrés sur le disque.
Si mysql te dit "les données sont enregistrés sur le disque", alors il faut comprendre qu'ils sont peut-être enregistrés sur le disque.
Et ce n'est même un bug temporaire. C'est un choix que fait Mysql pour être plus rapide. Tu vas dire que c'est une "feature".
C'est principalement pour cette raison que Mysql est plus rapide que postgresql. Mais dès qu'on monte en charge, l'avantage s'estompe car pendant l'attente d'un fsync postgresql a aussi autre chose à faire.
On le sait que Mysql ne supporte pas les test acid, je peux aussi t'affirmer qu'il ne supporte pas les coupures de courant.
[^] # Re: Bonne nouvelle
Posté par clearstream . En réponse au journal free & postgresql 8 & php 5. Évalué à 1.
[^] # Re: Bonne nouvelle
Posté par clearstream . En réponse au journal free & postgresql 8 & php 5. Évalué à 3.
La doc aussi est un bijou. Un grand bravo pour ce travail.
Postgresql est un bijou et pas plus compliqué à utiliser que mysql. D'ailleurs il est souvent plus simple d'utiliser postgresql que de se prendre la tête à contourner les limitations de mysql.
Il y a peut-être la configuration (!= utilisation) qui est plus compliqué. Mais ici la configuration est faite par free.
> quoique j'ai cru comprendre que mysql avait d'énormes progrès de ce côté
Je dois reconnaitre que je fuis mysql depuis plusieures années maintenant. Je l'ai utilisé jusqu'à la version 3.54 (?). Je n'ai pas regardé les versions suivantes (V4 et V5). Même pour des petits projets je préfère postresql.
> MySQL est "un poil" plus rapide,
Ça dépend. Pour les benchs probablement. Mais le manque de fonctionnalité de Mysql fait que tu donnes plus de boulot à php par exemple.
Faire un insert "brut" sous Mysql est plus rapide. Mais avec postgresql (et bien utilisé) tu fais l'insert et tous les contrôles (+requêtes annexes) sont faits. Avec mysql il faut locker les tables (donc la base est indisponible pour les autres), faires des requêtes pour voir si les nouvelles données sont ok, puis faire l'insert. Et ne parlons pas de problème compliqué avec transaction sur plusieurs tables. Au final (somme php+mysql), je doute que mysql donne un gain en performance .
Un peu de pub l'excelle pgadmin :
http://www.pgadmin.org/
copies d'écran : http://www.pgadmin.org/screenshots/
Cerise sur le gâteau, il marche aussi sous windows et mac.
Pour info, la beta de postgresql 8.2 est lancé :
http://www.postgresql.org/developer/beta
[^] # Re: Bonne nouvelle
Posté par clearstream . En réponse au journal free & postgresql 8 & php 5. Évalué à 5.
Un grand messieur à dit que 640 Ko était suffisant. Vu ce qui se faisait à l'époque, il avait raison.
Toi tu dis la même chose mais avec mysql.
Un autre a dit vers les débuts de Linux que le multitache ne sert à rien pour une station de travail ! A l'époque il avait aussi raison.
Tu veux revenir au systèmes monotaches avec 640 Ko ?
> Mais je n'arrive pas a voir quelles applications web auraient besoin d'un vrai SGBD
Il y a plein de code php/perl/etc qui font des trucs que DEVRAIENT faire le SGDB. Il le font car mysql ne sait pas le faire. Requêtes imbriquée, transaction, contrôle d'intégrité, rêgles, convertion de type de données, etc...
> un simple MySQL, qui, étant plus simple, est censé etre plus rapide.
Linux 1.2 est plus simple que Linux 2.6. Tu crois que Linux 1.2 est plus rapide que Linux 2.6 ?
[^] # Re: Bonne nouvelle
Posté par clearstream . En réponse au journal free & postgresql 8 & php 5. Évalué à 1.
Par contre postgresql à des fonctionnalité que n'a pas mysql (voir la doc). En plus il est mieux foutu (la gestion des dates sous mysql est à s'arracher les cheveux).
C'est vrai qu'un mec qui ne connais que mysql, qui crois qu'un SGBD ne peut faire que ce que fait mysql peut penser que postgresql ne sert à rien.
> je m'interroge sur son utilité pour les pages perso de Free.
Avec free tu as déjà 1 Go d'espace !
Et plus, il y a une option pour 10 Go d'espace !
Ça donne des idées.