There are a number of significant vulnerabilities in technologies relating to the IE domain/zone security model, the DHTML object model, MIME type determination, the graphical user interface (GUI), and ActiveX. It is possible to reduce exposure to these vulnerabilities by using a different web browser, especially when browsing untrusted sites. Such a decision may, however, reduce the functionality of sites that require IE-specific features such as DHTML, VBScript, and ActiveX. Note that using a different web browser will not remove IE from a Windows system, and other programs may invoke IE, the WebBrowser ActiveX control, or the HTML rendering engine (MSHTML).
Ce sont les technos Windows qui sont pointées du doigt.
Mozilla a pris la décision de ne pas supporter VBScript ni ActiveX pour des raisons de sécurité.
Windows est le plus mauvais système de l'histoire de l'informatique pour la sécurité.
Windows n'a pas été un peu plus mauvais mais beaucoup plus mauvais que tous les autres. A ce demander si leur fond de commerce n'est pas la création de faille de sécurité tellement Windows est généreux en innovations percées de trou de sécurité.
> Ah c'est marrant, RealPlayer, un truc qui lit des fichiers audio, il se met a ecouter sur 127.0.0.1:1275 2 users lancent RealPlayer, ah ben mince, ca marche pas !
007 a raison. Tu prends des exemple sur des serveurs ou des bugs et tu fais tes conclusions.
you can see, real player have a (Mini WebServer) that listen on port 1275
C'est un serveur et un bug. Quelque soit le système d'exploitation (ici windows) il faut corriger.
> Je sais que pour Redhat, le nom et le logo au chapeau rouge sont deposes. Est-ce les seules choses limitantes ?
Ça dépend. Pour RedHat, oui.
Fedora a moins de restriction puisque tu peux vendre aussi.
RHEL est "bizarre" car ce qui limite, c'est le support (et pas seulement la protection de la marque). Or pour avoir une RHEL il faut aussi acheter du support. Mais dès qu'il n'y a plus de support c'est de nouveau "normal". En même temps ce n'est pas un problème puisque des "faux-fork" (des copies) de RHEL existent et en toute légalité.
Il faut noter que la protection de la marque qu'utilise RedHat existe aussi pour les autres. Mais les autres le disent moins pour "faire plus cool". Mais toute personne qui utilise le nom Gentoo ou Mandrake ou Debian pour ce qui n'est pas du Gentoo ou du Mandrake ... se fera "allumé".
Sinon tous ce qui est ajouter à une distribution peut empêcher la distribution de l'ensemble de la distribution. Par contre ça ne peut pas empêcher la diffusion de gcc ou linux (qui sont sous GPL) de la distribution. La licence par programme reste pleinement appliqué.
Apparament il y a quelques difficultés avec ogg/theora :-)
Mais c'est une très bonne initiative de la part de akademy/KDE de proposer les flux dans un format totalement libre. Ça va populariser ce format et dans quelques mois il n'y aura plus de problème car toutes les distributions proposerons ogg/vorbis/theora en standard.
> L'intérêt de bittorrent, il me semble, est de pouvoir proposer en téléchargement des fichiers qui ne sont pas disponibles sur des miroirs avec une grosse bande passante.
Ce qui prouve que bittorrent allège le boulot des miroirs puisque bittorrent permet même de se passer de miroirs...
Pour les beta, bittorrent n'est pas très important. Par contre pour les premières jours d'une nouvelle distribution, les miroirs (même avec une grosse bande passante) sont à la ramasse...
Ou utiliser Rawhide. Actuellement en 3.3.0rc2 la version 3.3 va arriver dans très peu de temps.
FC3 est prévu avec KDE 3.3. FC3 test 2 est prévu pour début septemble (sûrement avec KDE 3.3). Comme en plus il y aura xorg 6.8 (actuellement 6.8.0rc2) on pourra jouer avec la transparence (actuellement un peu cassé et désactivé par défaut).
> Est-ce que quelqu'un pourrait expliquer en 2-3 mots (ou 2-3 liens) ce que c'est et ce que ca devrait apporter par rapport aux solutions existantes?
Plus ou moins rien :-)
C'est une abstraction supplémentaire mais dédié aux applications finales (utilisateurs).
Par exemple gphoto, aura moins de difficulter pour trouve la caméra et l'utiliser correctement.
C'est une idée d'Havoc, voilà l'explication : http://www.ometer.com/hardware.html(...)
udev : est une amélioration de hotplug avec d'autres goodies. udev remplace aussi devfs.
Pour le subjectif, ce que je n'aime pas dans KDE, c'est son absence d'"âme".
C'est un "truc" technologique qui s'apprécie à la lumière de ses fonctionnalités.
> Quand on a plusieurs centaines d'applis qui attaquent une base, elles ne doivent jamais le faire en direct.
C'est pour celà qu'il y a les views. Avec un "vrai" SGDB, tu n'attaques pas les tables qui stockent les données mais les views (ce qui permet aussi d'affiner les permissions). Après l'organisation ou le type des données peut changer sans que ça dérange les applis (si les views sont correctement mise à jours évidemment).
> Non c'est parce qu'il a été le premier à fournir une solution d'accès abordable
Red Hat a toujours eu parmis les meilleurs développeurs noyau. Puis des développeurs gcc/libc. Et depuis peu beaucoup de développeurs cluster. A ça t'ajoutes Gnome et son influence est impressionnante. Non ?
Pour la gestion de paquet, Red Hat a fait rpm. C'est pas rien.
> C'est bien que ça existe, c'est dommage que ce soit si cryptique d'utilisation et c'est peut-être pour cela que c'est si peu connu ?
C'est pas terrible rpmdb. On est d'accord.
rpmdb a été l'une des première solution pour récupérer les dépences avec rpm.
Exemple de etc/rpm/macros.solve : # The path to the dependency universe database. The default value
# is the rpmdb-fedora location. The macro is usually defined in
# /etc/rpm/macros.solve, installed with the rpmdb-redhat package.
%_solve_dbpath /usr/lib/rpmdb/i386-redhat-linux/redhat
# The path to the dependency universe packages. This should
# be a path to the packages contained in the solve database.
%_solve_pkgsdir /mnt/redhat/test/latest-i386/Fedora/RPMS/
# The output binary package file name template used when suggesting
# binary packages that solve a dependency. The macro is usually defined
# in /etc/rpm/macros.solve, installed with the rpmdb-redhat package.
#
# XXX Note: escaped %% for use in headerSprintf()
%_solve_name_fmt %%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm
A utiliser avec "rpm --iad" --aid add suggested packages to transaction
Mais tout ça ne marche pas avec le réseau et n'est pas multi-dépôts.
> ce n'est pas grâce à ses features que Red Hat est le "standard Linux de l'industrie".
Non c'est grace à son doux parfum de rose...
Côté feature, Red Hat n'a rien à démontrer et ça va beaucoup plus loin qu'un urpmi.
Red Hat à le nécessaire pour localiser un paquet, etc...
Mais il faut le connaitre.
Il y a rpmdb.
Exemple :
rpm -q -f --dbpath /usr/lib/rpmdb/i386-redhat-linux/redhat/ /usr/bin/gnucash
ou utiliser --whatprovides
L'option --whatprovides marche aussi avec up2date (qui est dans 100 % des Red Hat).
Généralement Red Hat (RHEL) est utilisé avec un abonnement rhn et le site web rhn permet de rechercher dans les paquets (up2date est fouille aussi dans les canaux rhn).
Puis il y a maintenant Fedora et dans Fedora il y a up2date et Yum. Fedora extra (l'officiel, supporté par Red Hat) propose aussi apt et synaptic.
Ben explique !
Comme fait ejb pour rendre Mysql transactionnel ?
Si une transaction c'est :
- modification table A
- modification table B
- modificaiton table C
Avec Mysql les 3 modifications seront faites une par une.
Avec PostgreSQL les 3 modifications seront visibles "d'un coup" ou ne seront pas visibles.
Donc comme fait ejb pour rend Mysql transactionnel (pense à plusieurs clients (ejb ou pas), à une coupure de courrant, un plantage, etc). S'il y a une coupure de courrant, les données qui seront utilisés seront ceux dans Myslq (donc avec des "transactions incomplètes"). Les objets persistants, etc n'interviennent pas ici puisque qu'il y a plus de courrant...
Le seul moyen pour que ce soit possible, c'est que ejb soit le seul point d'entré (il n'y a qu'une connection à la base de donnée). Alors c'est possible car il fait aussi serveur de base de données. Mais même dans ce cas la mission doit être ardue (impossible ?) avec Mysql...
Explique moi cette magie et pas en terme de :
- "tu verras que beaucoup de gens ont développé des solutions très propre, qui sont en production et qui font une abstraction de la base de données."
btw : arrête avec "une abstraction de la base de données", je sais ce que c'est et j'utilise. Merci.
> Il faut créer des fonctions creerCommande(idClient, date)... et c'est ainsi que les données seront cohérentes car on sera sur que chacun aura pas fait sa sauce dans son coin.
Par exemple il y a les triggers ou les rules sous PostgreSQL pour faire ça.
Lorsque tu fais :
insert into command (idClient, date) values (200, now) ;
PostgreSQL fera toutes les vérifications et bidouilles nécessaires. Que ce soit depuis php ou MS-Access et même EJB.
La "vrai" table est par exemple command_data et elle n'est pas inaccessible aux utilisateurs "normaux". Tout doit passer par des accès à la view command et là le développeur peux tout faire (au niveau donné).
Ainsi personne ne fait "sa sauce dans son coin" et ejb/java n'a pas l'exclusivité dans l'utilisation et la mise à jour des données.
> Les EJB tournent dans des serveurs d'applications J2EE comme Websphere, Weblogic, Oracle 9i AS, Sun One application serveur, JBoss ou JOnAS, ils sont transactionnels, gèrent les requêtes en parralèle, supporte le clustering....
Pour finir, je dirais qu'on peut développer sans se soucier de la base de données, c'est possible.
Ahahah.
C'est du discours de marketeux à la petite semaine.
Ce n'est pas possible. C'est tout. Faut pas chercher plus loin. Ou alors les ejb ça fait aussi gestionnaire de base de donnée avec support de transaction etc...
C'est tout simplement du bidon et c'est tout.
Juste un petit exemple. Ta base de donnée est Mysql et elle tourne sur un machine qui n'a pas d'ejb, etc. Par contre, tous les clients passent par ejb (via des middleware par exemple).
Ça rend mysql transactionnel ?
=> Non.
Tes clients voient des données gérées de façon transactionnelles (pas seulement car il font toto->begintransaction) ?
=> Non. (ou alors les middlewares communiques entre eux pour gérer les conflits).
Donc, s'il y a une coupure de courant et plusieurs clients qui écrivent à la foi, dans quel état sont les données au niveau Mysql ?
=> corrompus/incohents (btw, mysql peut tourner en local avec ejb (ou n'importe quoi d'autre) ça ne change rien).
M'enfin, si je me trompe, je veux bien que tu m'expliques par quelle magie noire c'est fait. Sauf si ejb fait aussi SGDB, c'est impossible. Il est inutile de connaitre ejb pour arriver à cette conclusion. C'est comme ça. Ce n'est pas pour rien que PostgreSQL est PostgreSQL, qu'Oracle est Oracle, etc...
Si Mysql pouvait remplacer au pied levé Oracle seulement en utilisant des ejb (ou n'importe quoi d'autre), ça se serait.
Ce que je veux dire (puis j'arrête...) c'est que tu ne peux pas mettre dos à dos les SGBD en disant :
- on s'en fout il y a les ejb ou autre
Ton exemple avec "tx.commit()" est limite comique. Si le SGDB en-dessous n'a pas de support de transaction, ton "tx.commit()" ne sert à rien (et ne fait sûrement rien :-) comme c'est le cas avec beaucoup de wrapper... ). Ou alors il faut vérrouiller toutes les tables (ou quelques tables "judicieusement choisies" (comprendre qu'un jour tu vas oublier de verrouiller une table ou que tu en verrouille une de trop)) et c'est une catastrophe pour la montée en charge, etc.
Pour les réservations de place d'avion ou train, tu ne peux pas faire ça sans un solide système transactionnel (ejb ou pas). Les ejb ne font pas de transactionnel, ne sont pas des serveurs qui supporte plusieurs requête en parallèle et doivent gérer le conflit, etc... Le transactionnel doit être fait au coeur du serveur de base de donnée (il n'y a pas le chois). C'est la même chose pour les contraintes si tu ne veux pas que tes backups soit pollués (parfois même à 3 heures du matin une base est utilisée...).
L'abstraction c'est bien. Mais une bonne base de donnée c'est bien aussi et c'est même parfois indispensable (que l'API de l'abstraction de donnée soit super élégante ou non).
btw : j'en profite pour dire que de faire une base de donnée solide (avec les bonnes contraintes, les controles d'intégrité, les mises à jours de données automatiques des données annexes, etc) c'est très dure.
Mais que c'est profidable après. L'utilisateur final peut utilise psql ou MS-Access, ou faire un script php, il n'y aura pas de problème côté donnée.
> mais que le développeur ne devrait plus avoir a se taper toutes les requetes sql bidons update, insert et delete par exemple pour gérer les données.
On est d'accord, mais tu fais du hors-sujet. Ce que tu dis est valable pour tous les développements et n'est absolument pas spécifique aux SGBD.
Si je prend l'exemple de la gestion d'utilisation.
SGBD : stockage et gestion des données. C'est le SGBD qui va vérifier qu'il n'y a pas de doublon dans les ID par exemple. Utilisation de SQL car on est au niveau des données.
Applicatif : utilisation de adduser(), deluser(), etc... et non de SQL car on est au niveau applicatif et pas donné. adduser() ajoute un utilisateur (point de vu applicatif) et n'ajoute pas un enregistrement à une table (sous Unix il y a "adduser" et pas "add_one_record_to_etc_passwd" (alors que cette fonction doit bien exister :-) )). Que ça utilise une base de donnée relationnelle ou que ça tripote /etc/passwd, au niveau applicatif on s'en fout. De même, avant de faire adduser() on ne va pas vérifier s'il y a doublon ou non. C'est le SGBD (ou autre) qui le fera (comme il gèrera les accès en écriture concurrent, etc). C'est ici (niveau applicatif) qu'on ajoutera une aide contextuelle etc car ce n'est pas lié aux données.
Notes que si tu laisses l'applicatif (ou une librairie) s'occuper de l'intégrité des données (par exemples comme avec Mysql) il est impossible de faire un backup à chaud avec des données cohérentes. Dans ce cas il y a toujours des moments ou les données sont incohérentes. C'est obligé ou alors tu as une base vraiment simple.
Si tu prends PostgreSQL et tu l'utilises comme Mysql, tes backups à chaud ne valent presque rien si les contrôles d'intégrités (contrainte/transaction/etc) ne sont pas fait au niveau du SGBD. Que t'utilise un ejb ne change rien à la problématique.
Bref, encore une fois tu décris les avantages d'avoir une abstraction supplémentaire par rapport à SQL. Tu n'as pas à me convaincre de ça mais c'est du hors-sujet.
> beh pour moi, quand on développe en objet, on doit etre indépendant de la bd.
C'est là que tu ne comprends pas...
SQL est indépendant de la bd. La base de donnée peut-être en mémoire vive ou n'importe où ailleur, ça ne change rien.
Tout ce que tu proposes, c'est de remplacer un standard par un autre. C-à-d remplacer SQL par ejb. Or l'objectif de SQL n'est pas celui de ejb (tel que le je comprend) et les deux peuvent cohabiter.
Par exemple SQL vérifie les données (ce que ne doit pas faire normalement l'applicatif ou ejb) et ton objet ejb indique que les ventes du mois ont été minables par rapport aux objectifs fixés par le patron (ce que ne fait pas SQL).
Déplacer ce qui doit être fait par le SGBD dans ejb (ou ailleur) car le SGBD est "insuffisant" n'est pas LA solution. C'est un workaround.
Si ton objectif est de dire qu'SQL n'est pas suffisament implémenté (ce qui est un problème pour l'intéropérabilité des bases de donnée (nb : je ne fais pas de hors-sujet)), et que ejb peut -être une solution pour contourner ce problème, alors je suis d'accord. Mais faut pas tout mélanger.
Ton "mapping", abstraction de donnée, etc... (avec ejb) est hors sujet. Cette problématique se pose pour les fichiers txt (gestion de named), exploitation du bus pci, etc...
> toutes les applis qui seront développés font appel à la logique métier des ejbs.
ejb est dans ce cas fait aussi "gestionnaire de donnée"...
On en revient toujours au même. Bien séparer l'applicatif et des données (stockage, vérification, etc...).
Notes que tu fais presque du hors-sujet. Là tu parles des abstractions base de donnée. Ces abstractions peuvent s'occuper de l'affichage par exemple ce qui n'est pas le rôle d'un SGBD.
Tu parles aussi spécifiquement de java. ejb ne marche pas pour un site web développé en php ou avec Visual basic. Si tu as intégre toute la partie gestion de données (stockage, vérification, etc) dans la base de donnée, tu es indépendant du language et peut utiliser java ou php etc...
En même temps, rien ne t'empêche d'utilise java pour les procédures embarquées dans la base de données...
Donc idéalement, il faut laisser au SGBD le rôle de gérer (et pas seulement stocker) les données. Ou tu considères que SQL n'est pas un standard d'accès aux données et que tu considère que ejb est le standard des systèmes d'accès aux SGBD. Mais il n'y a pas que Java.
> un exemple qui me vient là, dans le thread suivant on demande comment changer le type d'une colonne avec postgre, avec firebird c'est possible avec un alter column, firebird s'occupe du transtypage des données s'il est possible
# La distribution la plus rapide de l'été
Posté par Ayrton . En réponse au journal Mdk10.1 rc1 est dispo. Évalué à 1.
2004-09-04 Mandrakelinux 10.1 Release Candidate 1 ISOs available.
2004-08-22 Mandrakelinux 10.1 Beta 2 ISOs available.
2004-08-04 Mandrakelinux 10.1 Beta 1 ISOs available.
Un mois entre la première beta et la rc.
[^] # Re: Ah, le tas d'aneries habituel
Posté par Ayrton . En réponse au journal Unix : ton esprit fout le camp. Évalué à -3.
Tu lis des revues, tu sors, t'as Internet ?
T'es pas au courant que des sociétés abandonnent IE pour mozilla pour des raisons de sécurité ?
http://www.kb.cert.org/vuls/id/713878(...)
*Use a different web browser
There are a number of significant vulnerabilities in technologies relating to the IE domain/zone security model, the DHTML object model, MIME type determination, the graphical user interface (GUI), and ActiveX. It is possible to reduce exposure to these vulnerabilities by using a different web browser, especially when browsing untrusted sites. Such a decision may, however, reduce the functionality of sites that require IE-specific features such as DHTML, VBScript, and ActiveX. Note that using a different web browser will not remove IE from a Windows system, and other programs may invoke IE, the WebBrowser ActiveX control, or the HTML rendering engine (MSHTML).
Ce sont les technos Windows qui sont pointées du doigt.
Mozilla a pris la décision de ne pas supporter VBScript ni ActiveX pour des raisons de sécurité.
Windows est le plus mauvais système de l'histoire de l'informatique pour la sécurité.
Windows n'a pas été un peu plus mauvais mais beaucoup plus mauvais que tous les autres. A ce demander si leur fond de commerce n'est pas la création de faille de sécurité tellement Windows est généreux en innovations percées de trou de sécurité.
[^] # Re: Unix, c'etait mieux à vent, ton esprit fout le camp...
Posté par Ayrton . En réponse au journal Unix : ton esprit fout le camp. Évalué à -1.
007 a raison. Tu prends des exemple sur des serveurs ou des bugs et tu fais tes conclusions.
you can see, real player have a (Mini WebServer) that listen on port 1275
C'est un serveur et un bug. Quelque soit le système d'exploitation (ici windows) il faut corriger.
[^] # Re: package debian ?
Posté par Ayrton . En réponse au journal X11R6.8.0 devrait sortir aujourd'hui. Évalué à 3.
# Fedora
Posté par Ayrton . En réponse au journal X11R6.8.0 devrait sortir aujourd'hui. Évalué à 4.
Rawhide est en 6.8.0 RC2.
# ...
Posté par Ayrton . En réponse au message Question sur les licences des distributions (RedHat, Suse ...). Évalué à 2.
Ça dépend. Pour RedHat, oui.
Fedora a moins de restriction puisque tu peux vendre aussi.
RHEL est "bizarre" car ce qui limite, c'est le support (et pas seulement la protection de la marque). Or pour avoir une RHEL il faut aussi acheter du support. Mais dès qu'il n'y a plus de support c'est de nouveau "normal". En même temps ce n'est pas un problème puisque des "faux-fork" (des copies) de RHEL existent et en toute légalité.
Il faut noter que la protection de la marque qu'utilise RedHat existe aussi pour les autres. Mais les autres le disent moins pour "faire plus cool". Mais toute personne qui utilise le nom Gentoo ou Mandrake ou Debian pour ce qui n'est pas du Gentoo ou du Mandrake ... se fera "allumé".
Sinon tous ce qui est ajouter à une distribution peut empêcher la distribution de l'ensemble de la distribution. Par contre ça ne peut pas empêcher la diffusion de gcc ou linux (qui sont sous GPL) de la distribution. La licence par programme reste pleinement appliqué.
[^] # Re: comment lire les vidéos ?
Posté par Ayrton . En réponse à la dépêche The aKademy 2004 a commencé. Évalué à 2.
Mais c'est une très bonne initiative de la part de akademy/KDE de proposer les flux dans un format totalement libre. Ça va populariser ce format et dans quelques mois il n'y aura plus de problème car toutes les distributions proposerons ogg/vorbis/theora en standard.
[^] # Re: comment lire les vidéos ?
Posté par Ayrton . En réponse à la dépêche The aKademy 2004 a commencé. Évalué à 3.
$ mplayer Peter_Korn_The_State_of_Unix_Accessibility_video.ogg
MPlayer 1.0pre5-3.3.3 (C) 2000-2004 MPlayer Team
(...)
Playing Peter_Korn_The_State_of_Unix_Accessibility_video.ogg.
Cache fill: 0,10% (8192 bytes) Ogg file format detected.
(...)
Opening audio decoder: [libvorbis] Ogg/Vorbis audio decoder
AUDIO: 24000 Hz, 2 ch, 16 bit (0x10), ratio: 4000->96000 (32,0 kbit)
Selected audio codec: [vorbis] afm:libvorbis (OggVorbis Audio Decoder)
(...)
Selected video codec: [theora] vfm:theora (Theora (free, reworked VP3))
Normalement HelixPlayer de FC3T1 (+rawhide) doit aussi marcher.
NB : c'est la première fois que Red Hat diffuse un lecteur video ! Merci theora :-)
[^] # Re: Le logiciel "a la"
Posté par Ayrton . En réponse à la dépêche KDE 3.3 disponible. Évalué à 2.
On se demande où ils vont chercher tout ça !!
[^] # Re: les isos sont sur les miroirs
Posté par Ayrton . En réponse au journal Mandrake 10.1 beta2 dispo. Évalué à 4.
Ce qui prouve que bittorrent allège le boulot des miroirs puisque bittorrent permet même de se passer de miroirs...
Pour les beta, bittorrent n'est pas très important. Par contre pour les premières jours d'une nouvelle distribution, les miroirs (même avec une grosse bande passante) sont à la ramasse...
[^] # Re: Fedora
Posté par Ayrton . En réponse à la dépêche KDE 3.3 disponible. Évalué à 3.
Ou utiliser Rawhide. Actuellement en 3.3.0rc2 la version 3.3 va arriver dans très peu de temps.
FC3 est prévu avec KDE 3.3. FC3 test 2 est prévu pour début septemble (sûrement avec KDE 3.3). Comme en plus il y aura xorg 6.8 (actuellement 6.8.0rc2) on pourra jouer avec la transparence (actuellement un peu cassé et désactivé par défaut).
[^] # Re: Palabres et companie
Posté par Ayrton . En réponse à la dépêche KDE 3.3 disponible. Évalué à 5.
Plus ou moins rien :-)
C'est une abstraction supplémentaire mais dédié aux applications finales (utilisateurs).
Par exemple gphoto, aura moins de difficulter pour trouve la caméra et l'utiliser correctement.
C'est une idée d'Havoc, voilà l'explication :
http://www.ometer.com/hardware.html(...)
udev : est une amélioration de hotplug avec d'autres goodies. udev remplace aussi devfs.
dbus : un moyen de communication.
Gnome-Volume-Manager : j'ai oublié :-)
[^] # Re: Palabres et companie
Posté par Ayrton . En réponse à la dépêche KDE 3.3 disponible. Évalué à 4.
Pour le subjectif, ce que je n'aime pas dans KDE, c'est son absence d'"âme".
C'est un "truc" technologique qui s'apprécie à la lumière de ses fonctionnalités.
Je n'ai pas envis d'en faire ma compagne :-)
Retour à la techonologie : KDE adopte HAL ?
[^] # Re: Palabres et companie
Posté par Ayrton . En réponse à la dépêche KDE 3.3 disponible. Évalué à 1.
KDE, il y a un truc où je blo
Ce sont les barres d'outils avec les icones sans texte. Comme en plus les barres d'outils sont chargées => je fuis KDE.
Ce n'est pas très subjectif...
[^] # Re: La possibilité de changer le type d'une colonne avec ALTER TABLE.
Posté par Ayrton . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 2.
C'est pour celà qu'il y a les views. Avec un "vrai" SGDB, tu n'attaques pas les tables qui stockent les données mais les views (ce qui permet aussi d'affiner les permissions). Après l'organisation ou le type des données peut changer sans que ça dérange les applis (si les views sont correctement mise à jours évidemment).
[^] # Re: distro
Posté par Ayrton . En réponse au message Une fonction de RedHat me manque ( psselect ), comment l'obtenir ?. Évalué à 2.
Red Hat a toujours eu parmis les meilleurs développeurs noyau. Puis des développeurs gcc/libc. Et depuis peu beaucoup de développeurs cluster. A ça t'ajoutes Gnome et son influence est impressionnante. Non ?
Pour la gestion de paquet, Red Hat a fait rpm. C'est pas rien.
> C'est bien que ça existe, c'est dommage que ce soit si cryptique d'utilisation et c'est peut-être pour cela que c'est si peu connu ?
C'est pas terrible rpmdb. On est d'accord.
rpmdb a été l'une des première solution pour récupérer les dépences avec rpm.
Exemple de etc/rpm/macros.solve :
# The path to the dependency universe database. The default value
# is the rpmdb-fedora location. The macro is usually defined in
# /etc/rpm/macros.solve, installed with the rpmdb-redhat package.
%_solve_dbpath /usr/lib/rpmdb/i386-redhat-linux/redhat
# The path to the dependency universe packages. This should
# be a path to the packages contained in the solve database.
%_solve_pkgsdir /mnt/redhat/test/latest-i386/Fedora/RPMS/
# The output binary package file name template used when suggesting
# binary packages that solve a dependency. The macro is usually defined
# in /etc/rpm/macros.solve, installed with the rpmdb-redhat package.
#
# XXX Note: escaped %% for use in headerSprintf()
%_solve_name_fmt %%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm
A utiliser avec "rpm --iad"
--aid add suggested packages to transaction
Mais tout ça ne marche pas avec le réseau et n'est pas multi-dépôts.
[^] # Re: distro
Posté par Ayrton . En réponse au message Une fonction de RedHat me manque ( psselect ), comment l'obtenir ?. Évalué à 2.
Non c'est grace à son doux parfum de rose...
Côté feature, Red Hat n'a rien à démontrer et ça va beaucoup plus loin qu'un urpmi.
Red Hat à le nécessaire pour localiser un paquet, etc...
Mais il faut le connaitre.
Il y a rpmdb.
Exemple :
rpm -q -f --dbpath /usr/lib/rpmdb/i386-redhat-linux/redhat/ /usr/bin/gnucash
ou utiliser --whatprovides
L'option --whatprovides marche aussi avec up2date (qui est dans 100 % des Red Hat).
Généralement Red Hat (RHEL) est utilisé avec un abonnement rhn et le site web rhn permet de rechercher dans les paquets (up2date est fouille aussi dans les canaux rhn).
Puis il y a maintenant Fedora et dans Fedora il y a up2date et Yum. Fedora extra (l'officiel, supporté par Red Hat) propose aussi apt et synaptic.
Donc il n'y a aucun problème ici.
Par contre, RH 9 n'est plus supporté...
[^] # Re: Et mysql
Posté par Ayrton . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 3.
Ben explique !
Comme fait ejb pour rendre Mysql transactionnel ?
Si une transaction c'est :
- modification table A
- modification table B
- modificaiton table C
Avec Mysql les 3 modifications seront faites une par une.
Avec PostgreSQL les 3 modifications seront visibles "d'un coup" ou ne seront pas visibles.
Donc comme fait ejb pour rend Mysql transactionnel (pense à plusieurs clients (ejb ou pas), à une coupure de courrant, un plantage, etc). S'il y a une coupure de courrant, les données qui seront utilisés seront ceux dans Myslq (donc avec des "transactions incomplètes"). Les objets persistants, etc n'interviennent pas ici puisque qu'il y a plus de courrant...
Le seul moyen pour que ce soit possible, c'est que ejb soit le seul point d'entré (il n'y a qu'une connection à la base de donnée). Alors c'est possible car il fait aussi serveur de base de données. Mais même dans ce cas la mission doit être ardue (impossible ?) avec Mysql...
Explique moi cette magie et pas en terme de :
- "tu verras que beaucoup de gens ont développé des solutions très propre, qui sont en production et qui font une abstraction de la base de données."
btw : arrête avec "une abstraction de la base de données", je sais ce que c'est et j'utilise. Merci.
[^] # Re: Et mysql
Posté par Ayrton . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 2.
Par exemple il y a les triggers ou les rules sous PostgreSQL pour faire ça.
Lorsque tu fais :
insert into command (idClient, date) values (200, now) ;
PostgreSQL fera toutes les vérifications et bidouilles nécessaires. Que ce soit depuis php ou MS-Access et même EJB.
La "vrai" table est par exemple command_data et elle n'est pas inaccessible aux utilisateurs "normaux". Tout doit passer par des accès à la view command et là le développeur peux tout faire (au niveau donné).
Ainsi personne ne fait "sa sauce dans son coin" et ejb/java n'a pas l'exclusivité dans l'utilisation et la mise à jour des données.
[^] # Re: Et mysql
Posté par Ayrton . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 2.
Pour finir, je dirais qu'on peut développer sans se soucier de la base de données, c'est possible.
Ahahah.
C'est du discours de marketeux à la petite semaine.
Ce n'est pas possible. C'est tout. Faut pas chercher plus loin. Ou alors les ejb ça fait aussi gestionnaire de base de donnée avec support de transaction etc...
C'est tout simplement du bidon et c'est tout.
Juste un petit exemple. Ta base de donnée est Mysql et elle tourne sur un machine qui n'a pas d'ejb, etc. Par contre, tous les clients passent par ejb (via des middleware par exemple).
Ça rend mysql transactionnel ?
=> Non.
Tes clients voient des données gérées de façon transactionnelles (pas seulement car il font toto->begintransaction) ?
=> Non. (ou alors les middlewares communiques entre eux pour gérer les conflits).
Donc, s'il y a une coupure de courant et plusieurs clients qui écrivent à la foi, dans quel état sont les données au niveau Mysql ?
=> corrompus/incohents (btw, mysql peut tourner en local avec ejb (ou n'importe quoi d'autre) ça ne change rien).
M'enfin, si je me trompe, je veux bien que tu m'expliques par quelle magie noire c'est fait. Sauf si ejb fait aussi SGDB, c'est impossible. Il est inutile de connaitre ejb pour arriver à cette conclusion. C'est comme ça. Ce n'est pas pour rien que PostgreSQL est PostgreSQL, qu'Oracle est Oracle, etc...
Si Mysql pouvait remplacer au pied levé Oracle seulement en utilisant des ejb (ou n'importe quoi d'autre), ça se serait.
[^] # Re: Et mysql
Posté par Ayrton . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 2.
- on s'en fout il y a les ejb ou autre
Ton exemple avec "tx.commit()" est limite comique. Si le SGDB en-dessous n'a pas de support de transaction, ton "tx.commit()" ne sert à rien (et ne fait sûrement rien :-) comme c'est le cas avec beaucoup de wrapper... ). Ou alors il faut vérrouiller toutes les tables (ou quelques tables "judicieusement choisies" (comprendre qu'un jour tu vas oublier de verrouiller une table ou que tu en verrouille une de trop)) et c'est une catastrophe pour la montée en charge, etc.
Pour les réservations de place d'avion ou train, tu ne peux pas faire ça sans un solide système transactionnel (ejb ou pas). Les ejb ne font pas de transactionnel, ne sont pas des serveurs qui supporte plusieurs requête en parallèle et doivent gérer le conflit, etc... Le transactionnel doit être fait au coeur du serveur de base de donnée (il n'y a pas le chois). C'est la même chose pour les contraintes si tu ne veux pas que tes backups soit pollués (parfois même à 3 heures du matin une base est utilisée...).
L'abstraction c'est bien. Mais une bonne base de donnée c'est bien aussi et c'est même parfois indispensable (que l'API de l'abstraction de donnée soit super élégante ou non).
btw : j'en profite pour dire que de faire une base de donnée solide (avec les bonnes contraintes, les controles d'intégrité, les mises à jours de données automatiques des données annexes, etc) c'est très dure.
Mais que c'est profidable après. L'utilisateur final peut utilise psql ou MS-Access, ou faire un script php, il n'y aura pas de problème côté donnée.
[^] # Re: Et mysql
Posté par Ayrton . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 3.
On est d'accord, mais tu fais du hors-sujet. Ce que tu dis est valable pour tous les développements et n'est absolument pas spécifique aux SGBD.
Si je prend l'exemple de la gestion d'utilisation.
SGBD : stockage et gestion des données. C'est le SGBD qui va vérifier qu'il n'y a pas de doublon dans les ID par exemple. Utilisation de SQL car on est au niveau des données.
Applicatif : utilisation de adduser(), deluser(), etc... et non de SQL car on est au niveau applicatif et pas donné. adduser() ajoute un utilisateur (point de vu applicatif) et n'ajoute pas un enregistrement à une table (sous Unix il y a "adduser" et pas "add_one_record_to_etc_passwd" (alors que cette fonction doit bien exister :-) )). Que ça utilise une base de donnée relationnelle ou que ça tripote /etc/passwd, au niveau applicatif on s'en fout. De même, avant de faire adduser() on ne va pas vérifier s'il y a doublon ou non. C'est le SGBD (ou autre) qui le fera (comme il gèrera les accès en écriture concurrent, etc). C'est ici (niveau applicatif) qu'on ajoutera une aide contextuelle etc car ce n'est pas lié aux données.
Notes que si tu laisses l'applicatif (ou une librairie) s'occuper de l'intégrité des données (par exemples comme avec Mysql) il est impossible de faire un backup à chaud avec des données cohérentes. Dans ce cas il y a toujours des moments ou les données sont incohérentes. C'est obligé ou alors tu as une base vraiment simple.
Si tu prends PostgreSQL et tu l'utilises comme Mysql, tes backups à chaud ne valent presque rien si les contrôles d'intégrités (contrainte/transaction/etc) ne sont pas fait au niveau du SGBD. Que t'utilise un ejb ne change rien à la problématique.
Bref, encore une fois tu décris les avantages d'avoir une abstraction supplémentaire par rapport à SQL. Tu n'as pas à me convaincre de ça mais c'est du hors-sujet.
[^] # Re: Et mysql
Posté par Ayrton . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 3.
C'est là que tu ne comprends pas...
SQL est indépendant de la bd. La base de donnée peut-être en mémoire vive ou n'importe où ailleur, ça ne change rien.
Tout ce que tu proposes, c'est de remplacer un standard par un autre. C-à-d remplacer SQL par ejb. Or l'objectif de SQL n'est pas celui de ejb (tel que le je comprend) et les deux peuvent cohabiter.
Par exemple SQL vérifie les données (ce que ne doit pas faire normalement l'applicatif ou ejb) et ton objet ejb indique que les ventes du mois ont été minables par rapport aux objectifs fixés par le patron (ce que ne fait pas SQL).
Déplacer ce qui doit être fait par le SGBD dans ejb (ou ailleur) car le SGBD est "insuffisant" n'est pas LA solution. C'est un workaround.
Si ton objectif est de dire qu'SQL n'est pas suffisament implémenté (ce qui est un problème pour l'intéropérabilité des bases de donnée (nb : je ne fais pas de hors-sujet)), et que ejb peut -être une solution pour contourner ce problème, alors je suis d'accord. Mais faut pas tout mélanger.
Ton "mapping", abstraction de donnée, etc... (avec ejb) est hors sujet. Cette problématique se pose pour les fichiers txt (gestion de named), exploitation du bus pci, etc...
[^] # Re: Et mysql
Posté par Ayrton . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 3.
ejb est dans ce cas fait aussi "gestionnaire de donnée"...
On en revient toujours au même. Bien séparer l'applicatif et des données (stockage, vérification, etc...).
Notes que tu fais presque du hors-sujet. Là tu parles des abstractions base de donnée. Ces abstractions peuvent s'occuper de l'affichage par exemple ce qui n'est pas le rôle d'un SGBD.
Tu parles aussi spécifiquement de java. ejb ne marche pas pour un site web développé en php ou avec Visual basic. Si tu as intégre toute la partie gestion de données (stockage, vérification, etc) dans la base de donnée, tu es indépendant du language et peut utiliser java ou php etc...
En même temps, rien ne t'empêche d'utilise java pour les procédures embarquées dans la base de données...
Donc idéalement, il faut laisser au SGBD le rôle de gérer (et pas seulement stocker) les données. Ou tu considères que SQL n'est pas un standard d'accès aux données et que tu considère que ejb est le standard des systèmes d'accès aux SGBD. Mais il n'y a pas que Java.
PS : connais pas vraiment ejb.
[^] # Re: C'est pas pour troller mais...
Posté par Ayrton . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 3.
Bon ... ben ... comme avec PostgreSQL V8...