La future version du système d'exploitation (OS X Tiger) qui sortira dans la première moitié de 2005 comprendra entre autres :
- Intégration d'un serveur iChat basé sur Jabber avec possibilité de crypter les conversations (protocole ouvert)
- Intégration de SQLite dans l'OS (licence : domaine public)
- Serveur weblog intégré basé sur Blojsom (licence : BSD)
- GCC version 3.5 avec auto-vectorisation du code pour Altivec (licence : GPL)
- Système de Build basé sur Ant (licence : Apache) et support de Subversion (licence : Apache).
PS1: Tiger intègre un système de fichier à-la-BeOS qui permet des recherches ultra-rapides et les live-queries (technologie Spotlight)... avec le WinFS de Longhorn à l'horizon il apparaît urgent que le libre se mobilise pour avoir un équivalent (Storage pour Gnome ?).
PS2 : L'annonce de GCC version 3.5 est étrange sachant que nous en somme à la 3.4 et que les développeurs hésitent à nommer la suivante 3.5 ou 4.0. Il semble qu'Apple maintienne sa politique d'intégration de "briques" libres dans son système afin de profiter facilement de ces technologies et (indirectement) de faciliter l'interopérabilité.
On peut évidemment se poser la question de savoir si Apple ne fait que se servir cyniquement ou si la firme contribue en retour aux logiciels libres.
Il semble que le modèle commercial en vigueur consiste à proposer une interface homme-machine propriétaire très intégrée et très intuitive (Quartz et les i-apps) au-dessus d'un système ouvert et libre (Darwin et les briques de FreeBSD 5.x).
Pour parvenir à ce résultat Apple privilégie les technologies qui ne l'obligent pas à libérer ses développements (BSD) et n'utilise du code GPL (NdM: LGPL pour KHTML) que lorsqu'il n'existe pas d'alternative (KHTML dans Safari ou le compilateur GCC).
Le bon coté des choses est qu'Apple facilite ainsi la diffusion des protocoles standardisés et ouverts.
Aller plus loin
- Les nouveautés de Tiger (2 clics)
- La couche Unix de Tiger (1 clic)
- Un pdf sur Storage (1 clic)
# De l'essort d'un IM
Posté par Wawet76 (site web personnel) . Évalué à 10.
Un client Jabber de série sur tous les Mac, ça donnerait surement un bon coup de fouet. Mmmmhhhh...
[^] # Re: De l'essort d'un IM
Posté par ploum (site web personnel, Mastodon) . Évalué à 5.
Souvenez-vous de Wanadoo, qui proposait un wanadoo-chat, en fait un serveur Jabber qui n'acceptait pas les autres clients Jabber que son wanadoo-client.
Ce qui fait que même en utilisant un protocole 100% libre et ouvert, ils ont réussi à empêcher toute interopérabilité.
Mais si c'est 100% compatible, alors c'est vrai que ce serait génial...
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: De l'essort d'un IM
Posté par Olivier . Évalué à 6.
Based on the open source Jabber project, the new iChat server in Tiger Server lets your company protect its internal communications by defining its own namespace, using SSL/TLS encryption to ensure privacy, and Kerboros for authorization. The iChat server works with both the iChat client in Mac OS X Tiger and popular open source clients available for Windows, Linux and even PDAs.
Donc on peut penser que ce sera compatible avec les clients Jabber existants (sans présager du fait qu'ils vont ou non ajouter des fonctionnalités). Donc c'est une bonne nouvelle :) !
Bob
# Apple esr réglo
Posté par gallenza . Évalué à 6.
[^] # Re: Apple esr réglo
Posté par Christophe Fergeau . Évalué à 8.
[^] # Re: Apple esr réglo
Posté par Olivier . Évalué à 2.
Effectivement c'est précis :)
Non, sérieusement, si on peut critiquer l'attitude de la branche matérielle d'Apple en ce qui concerne l'absence de specs de son matériel (ce qui complique effectivement pas mal la vie des dev de drivers PPC), son attitude en temps que fabriquant d'OS est vraiment réglo, non seulement parce qu'ils reversent toutes les modifs qu'ils font et parce qu'ils participent aux développements des logiciels qu'ils utilisent, mais aussi parce qu'ils ont mis certains de leurs projets en OpenSource (sous une licence compatible GPL), par exemple RendezVous ou leur StreamingServer.
Donc ne confondons pas tout, svp
[^] # Re: Apple esr réglo
Posté par Christophe Merlet (site web personnel) . Évalué à 4.
Certes apple respecte les licences des logiciels qu'ils utilisent, c'est la moindre des choses.
Cependant je constate que les modifications qu'apporte Apple aux divers logiciels qu'ils utilisent ne profite qu'a macos x.
Alors que les apports de IBM ou de Sun profite à tous quelque soit le matériel ou l'OS ! La différence dans l'approche logiciel libre d'apple et des autres sociétés est quand meme trés différente. Apple se contente d'adapter et d'intéger des logiciels libres à leur système alors que les autres constructeurs les font _progresser_.
Je serais heureux d'apprendre qu'apple a amélioré les performances de MySQL, d'apache, de samba, etc... mais il n'en est rien. Ils ont juste corrigé khtml pour pouvoir le compiler sur cocoa et le rendre compatible avec les bugs d'IE. Je trouve cette contribution assez maigre.
[^] # Re: Apple esr réglo
Posté par peau chat . Évalué à 6.
Ah non ! Ils ont fait carrément bcp plus que cela sur KHTML, et ils ont documenté/intégré leurs modificiations dans KHTML.
Par exemple, ils ont quasiment entièrement réécrit le gestionnaire de mémoire.
[^] # Re: Apple esr réglo
Posté par Olivier . Évalué à 3.
Là, c'est clairement du FUD...
Ne serait-ce que la première contribution d'Apple (juste après avoir rendu public Safari) dont voici le ChangeLog suffit à prouver le contraire :
http://lists.kde.org/?l=kfm-devel&m=104196912316326&w=2(...)
On est loin améliorations superficielles dont tu parles...
[^] # Re: Apple esr réglo
Posté par Colin Leroy (site web personnel) . Évalué à 3.
Le reste (son, ethernet, usb, sous-système IDE, etc) fonctionne très, très bien sous linux... y compris les radeons jusqu'à la 9200 .
# GCC et Altivec
Posté par A-Wai . Évalué à 5.
(mmh, je suis pas sur d'avooir été très clair là...)
Mais j'avais cru comprendre en suivant quelques discussions diverses et variées que ça n'était pas prêt de changer, d'où ma question : où en sont actuellement les développeurs de GCC ? peut-on espérer cette "killer feature" dans un futur proche ?
[^] # Re: GCC et Altivec
Posté par Gwenole Beauchesne . Évalué à 3.
# Commentaire du commentaire
Posté par fleny68 . Évalué à 8.
Oui, je me la suis posée aussi après l'anonce du X11 version Apple: la licence n'obligeant pas à un reversement des modifications, c'était un point important. Or Apple a publié (je ne sais pas si c'est toujours disponible mais pourquoi l'aurait il enlevé?) les sources de son X11 modifié.
Ce commentaire ressemble assez à un procès d'intention, ou alors il faut donner des exemples dans le sens inverse...
Il semble que le modèle commercial en vigueur consiste à proposer une interface homme-machine propriétaire très intégrée et très intuitive (Quartz et les i-apps) au-dessus d'un système ouvert et libre (Darwin et les briques de FreeBSD 5.x).
ça c'est exact, tout est loin d'être en logiciels libres chez Apple.
[^] # Re: Commentaire du commentaire
Posté par Pierre Tramo (site web personnel) . Évalué à 2.
Il faut quand même voir que le serveur X11 pour MacOS X a été créé à des fins d'interropérabilité, à la demande des utilisateurs. Et ça n'est pas un produit stratégique destiné à séduire et attirer de nouveaux clients comme Aqua. Bref Aqua : stratégique, grosse valeur ajoutée -> proprio et maintenu par une équipe dédiée ; serveur X11 : vite fait pour accroître la compatibilité avec les autres Unix, n'évoluera probablement pas beaucoup -> on le laisse dans la nature pour laisser d'éventuels utilisateurs motivés le corriger ou l'améliorer, sans avoir à supporter le coût d'une équipe dédiée.
Si Apple a fourni les sources, ce n'est pas par philanthropie, mais juste parce que c'est préférable financièrement.
Apple participera activement au Logiciel Libre quand ils auront libéré les sources de leur interface graphique. Mais jusque là, c'est juste un vendeur d'OS proprio avec des bouts de libre dedans.
[^] # Re: Commentaire du commentaire
Posté par - - . Évalué à 4.
tout cela fut récupéré par Xfree.
[^] # Re: Commentaire du commentaire
Posté par xylpho . Évalué à 4.
pour ne pas se cogner trop fort la tête sur le bureau en cas de copier/coller.
C'est grâce à ce détail infime que j'ai pu copier/coller mes cookies pour le coincoin. Sinon c'était galère. Je sais c'est un détail infime. Mais c'est LE détail qui fait que Apple, Panther, voilà quoi.
--off
Autre détail infime qui m'a amusé. J'ai constaté qu'Itunes et son système de recherche roxor. Le temps qu'un collègue sur XP réfléchisse à comment s'appelle tel ou tel mp3, je suis déjà en train de l'écouter (bon j'ai que 2000 tracks mais j'ai essayé sur plus, ça marche pareil). C'est vrai, sur XP Itunes c'est lourd et mal optimisé, on peut pas le skinner (rhoo vraiment quel dommage ma petite dame) mais bon l'interface neon proto prout quand je bosse sur Maya je m'en cogne un peu non? Puisque quand j'ai lancé Itunes c'est pour écouter de la zique.
--/off
[^] # Re: Commentaire du commentaire
Posté par Euclide (site web personnel) . Évalué à 1.
> d'interropérabilité, à la demande des utilisateurs. Et ça n'est pas un produit
> stratégique destiné à séduire et attirer de nouveaux clients comme Aqua
Heu perso, la présence de X11 en natif dans MacOS X est une des raisons qui font que j'utilise cet OS sur mon powerbook (et j'ai le choix, puisque j'ai aussi une Debian sur la meme machine)
# Difficile de critiquer Apple(tm) sur son utilisation du libre
Posté par Snark_Boojum . Évalué à 10.
Et il ne me semble pas que ce soit le seul cas où ils ont:
* utilisé un projet libre;
* dit qu'ils utilisaient un projet libre (ie: ils font de la pub pour ce projet);
* proposé des améliorations à ce projet (même si la licence ne le rendait pas obligatoire).
En résumé : certes, c'est un système qui n'est pas aussi libre qu'on peut le vouloir, néanmoins ils ont fait leurs choix, ont bien respecté les licences et se sont montrés très corrects.
Snark
# khtml sans alternative?
Posté par zorel . Évalué à 2.
Euh, j'aurais même plutôt tendance à dire que khtml est l'alternative face à Gecko.
[^] # Re: khtml sans alternative?
Posté par Pierre Tramo (site web personnel) . Évalué à 1.
[^] # Re: khtml sans alternative?
Posté par jmfayard . Évalué à 2.
[^] # Re: khtml sans alternative?
Posté par patrick_g (site web personnel) . Évalué à 2.
j'étais persuadé que c'était sous GPL !
De toute façon Apple avait indiqué qu'ils ont choisi KHTML pour ses qualités techniques (compacité) par rapport à Gecko.
# Spotlite/WinFS et ce genre de choses.
Posté par zorel . Évalué à 7.
Pourquoi? Pour sans arrêt copier les nouveautés des logiciels propriétaires? Personnellement, j'aimerai qu'on m'explique l'intêret d'avoir un système comme ça, je n'en vois pas l'intêret. Je n'ai pas dit qu'il n'existait pas, j'en vois même beaucoup d'applications, mais pour un pécé de bureau, je vois pas.
Et, tiens, je lisais l'Excellentissime Histoire des Pingouins, et dans un des chapitres, ça parle de copie sur les technos de l'Empire. finalement, on retrouve beaucoup de ça dans Gnome, KDE et cie: la copie de ce qui semble bien dans les logiciels/OS propriétaire. J'en viens parfois à me demander si Gates n'a pas raison quand il dit que l'innovation (la vraie, pas la création d'un nouveau logiciel qui regroupe les capacités de 42 autres ou une nouveauté dans l'interface) vient forcément des logiciels proprios.
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par djano . Évalué à 7.
Propriétaire ne veut pas dire non-innovant.
Oui les logiciels propriétaires peuvent-être innovants! Tout comme ils ne le sont parfois pas du tout. Ils sont souvent innovants lorsqu'ils visent à détrôner un logiciel leader (lui même proprio, sinon, ils n'essayent même pas). Ils le sont beaucoup moins lorsqu'ils sont leaders de leur marché.
Ma remarque vaut également pour les logiciels libres : ils deviennent souvent moins innovants lorsqu'ils deviennent leaders et sont remplacés si un projet plus dynamique (plus innovant) apparaît (ex celebre : vi -> vim).
Pourquoi? Pour sans arrêt copier les nouveautés des logiciels propriétaires?
On ne copie pas sans arrêt les nouveautés des logiciels propriétaires. On copie les bonnes idées tout court.
D'ailleurs, si les logiciels propriétaires sortent tant de bonnes idées en ce moment, c'est peut-être qu'ils ont justement besoin de se démarquer (qui a dit "la trouille de perdre leur monopole?")
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par zorel . Évalué à 2.
Personnellement, je ne considère pas vim comme innovant. Ce n'est pour moi (qui ne l'utilise pas, étant utilisateur d'Emacs (¹) qu'un ajout de fonctionnalité par rapport à vi. Même s'il ajout BEAUCOUP plus de fonctionnalité. Je pensais plutôt aux recherches de Sun sur les interfaces utilisateurs par exemple.
(qui a dit "la trouille de perdre leur monopole?")
Justement là encore, je ne pense pas que Microsoft soit un exemple dans l'innovation. Je pense plutôt que les logiciels propriétaires réellement innovants ne viennent que des sociétés qui ont un positionnement marginal (genre Apple (¹)) qui innovent réellement pour se démarquer non pas du logiciel libre mais de Microsoft.
¹ hein? un troll?
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par Christophe Merlet (site web personnel) . Évalué à -3.
Faut arrêter avec les idée reçu. Apple qui innove c'était vrai ya 20 ans. Aujourd'hui ce n'est absolument plus le cas. Hélas avec beaucoup de marketing on peut faire croire tout ce qu'on veut, yaura toujours des naifs pour écouter religieusement les sirènes de la pub.
Osser dire aujourd'hui qu'apple innove alors qu'ils ne font qu'intégrer un système BSD complet librement accessible sur internet avec une interface graphique propriétaire est franchement ridicule.
Apple remontera dans mon estime si il arrive a faire tourner Mac OS X plus vite que Linux sur mon iMac DV SE !
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par - - . Évalué à 3.
par exemple, l'autoconfiguration de tcp/ip, l'auto découverte de services, le grid avec xgrid, etc
y a aussi énorméments de détails dans le soin apporté à l'interface , dans l"utilisation des logiciels apple etc.
le "spotlight" est une innovation vu que c'est globalement la première fois que les "gens" (mr tout le monde et madame tout le monde) vont avoir un aussi puissant (et simple) outil d'indexation et de récupération de documents et autres informations
c'est un exemple parmis tant d'autres
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par Christophe Merlet (site web personnel) . Évalué à 2.
FAUX, C'était déjà le cas avec Sherlock dans mac os 8 (en 1998) et sherlock n'était déjà qu'une repompe d'un outil qui s'appelait Watson !
Par ailleurs indexer les fichiers dans une base de données pour accélerer les recherches est trés vieux déjà dispo dans mac os 8, dans windows depuis Office 97 ou sous linux avec htdig ou medusa.
Encore une victime de la pub qui croient que mme michou va enfin pouvoir retrouver son document texte sans avoir à se souvenir de là ou elle l'a enregistré grace à apple (ou microsoft lors de la prochaine pub pour win...) !
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par gallenza . Évalué à -1.
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par Christophe Merlet (site web personnel) . Évalué à 2.
Si tu installe mac os 8.5 sur un bi-G5 je suis convaincu aussi que Sherlock ira aussi vite que ce fameux Spotlight que personne n'a d'ailleurs eu la possibilité d'utiliser !
Sinon, à part ça, tu crois que si j'achéte cette fameuse crème antiride vu à la tv j'aurais l'air 10 ans de moins ? Est ce que je peux vraiment perdre 20 kg en 2 semaines en achetant rien que des produits "light" au supermarché?
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par gaolinn . Évalué à 1.
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par ArBaDaCarBa . Évalué à 3.
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par Paerro Trime . Évalué à 0.
ouais alors fais ce que tu dis pour commencer (et c'est reçues). QuickTime et OpenDoc par exemple ont été de vrais innovations en leur temps, il s'est passé des trucs dans les années 80 et même 90 aussi. Et ça concerne pas que Apple et pas que les interfaces graphiques.
> Apple remontera dans mon estime si il arrive a faire tourner Mac OS X plus vite que Linux sur mon iMac DV SE !
Le jour où ton Linux fonctionnera sur ton iMac truc machin avec un système de fenêtrage qui utilise intégralement le compositing à la moitié de la vitesse de Mac OS X, on aura déjà passé une belle étape.
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par Christophe Merlet (site web personnel) . Évalué à 1.
http://www.redfoxcenter.org/MacOS/techno/penguinatwork.gif(...)
A l'époque j'ai était tellement naif que j'ai cru qu'ils étaient en train de faire un portage de quicktime sous linux :((((
Opendoc, cette technologie mort-né tellement elle était compliqué à utiliser et sous performante ? Faut dire qu'utiliser du code 68k en émulation sur des pov powerpc à moins de 100 MHz c'était un vrai trait de génie ! "Think Different" qu'ils disaient à l'époque ;o)
En 97 je disais déjà ça d'Opendoc : "Technologie similaire à OLE permettant de créer des liens entre les fichiers provenant de differentes applications (une page WEB dans une cellule de tableur par exemple). Aux dernieres nouvelles cette technologie sera abandonnée dans le futur Rhapsody au profit de composants Java. Alors là... je crains pour les performance du système. Vu que JAVA, même avec un compilateur JIT, c'est pas foudre de guerre !!"
Innovation ? C'est bien de ça qu'on parle ?
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par Paerro Trime . Évalué à 1.
Tout à fait. Encore faut-il savoir de quoi on parle et pas recopier des brêves dans sa collec de vieux numéros de "Décision coin coin" ou "01/20 en informatique".
QuickTime lors de la sortie de la version 1.0 en 1991 était incontestablement innovant ; l'histoire du pingouin, c'est une péripétie totalement postérieure et dont surtout on a dû mal à voir le rapport avec la choucroute.
OpenDoc n'avait rien à voir techniquement avec OLE. C'était une technologie de composants, avec persistance et tout le tralala. Elle est effectivement morte depuis longtemps et l'implémentation était fortement plombée par les lacunes fondamentales de deux des trois OS sur laquelle elle était implémentée (MacOS et Windows 3.1 pour par les nommer) ; mais ça change rien au fait qu'elle était innovante sur le fond au moment de sa sortie en 95.
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par gaolinn . Évalué à 1.
OpenDoc : Conception totalement différentes des autres application. Le point central n'étant plus le programme mais le document. On lance un document qui va charger les module qui lui sont nécessaires. Plus besoin d'un mastodonte style M$ Word ou Excel voir OpenOffice, juste quelques composants interchangeable. Ex. le dictionnaire ou l'éditeur d'équation ou..., si celui de base ne te plais pas, tu le remplace par un autre, au lieu de remplacer toute l'application. Plus d'application monolithique mais un assemblage de composants indépendant des autres et interchangeable.
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par jmfayard . Évalué à 2.
Si je comprends bien, Apple a échoué à faire ce que KDE a aujourd'hui avec son architecture KParts && DCop && cie
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par gaolinn . Évalué à 1.
[^] # hors sujet : un zoli pingouin
Posté par Jimmy . Évalué à 2.
http://www.redfoxcenter.org/MacOS/techno/penguinatwork.gif(...(...))
Savez-vous où on peut trouver ce pingouin dans sa version orignale ? Je le trouve super sympa, et j'aimerais en mettre partout si il n'est pas copyrighté ...
J'avais même tenté il y a quelques années, sans gros succès, d'effacer le logo Quicktime sur son ventre (il n'avait alors ni casque, ni outils)
JiM
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par Philippe F (site web personnel) . Évalué à 1.
Si tu veux chercher de l'innovation cote vi, va plutot voir yzis: www.yzis.org
- integration dans des framework de composants graphiques
- separation entre gui et moteur vi
- code structure et oriente objet (il faut voir les sources de vim - en C pre-ansi - pour comprendre l'interet de celui-la)
- utilisation d'un langage de script existant (lua) au lieu d'un truc fait maison
- integration dans Kate, KDevelop, Quanta
Et bien plus a venir bientot
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par Miair Patreau . Évalué à 3.
Ben, les recherches ultra-rapides, ya des gens devant leur PC qui aiment ça, hein :-).
Et un paquet de gens refusent de passer à autre chose que MS uniquement parce que autre chose que MS fait les choses autrement que MS. Est-ce une raison pour se passer de leur influence ? (Ou de les laisser sombrer dans la non-pérennité de leurs données, si on se sent l'âme salvatrice.)
De plus, un système de fichier a toujours été une base de données, et l'implémenter suivant tous les différents modèles de systèmes de bases de données a toujours été imaginé. Rien d'innovant.
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par dommtp . Évalué à 2.
Peu importe de savoir où se trouve un document sur ton disque, ce qui t'importes, c'est de le trouver rapidement et facilement. Or pour faire une recherche rapide et fiable sur plusieurs dizaine de Go, il faut une indexation efficace, et si ton systeme de fichier est concu pour ca, ca facilite bien les choses.
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par zorel . Évalué à 3.
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par xylpho . Évalué à 10.
Si vous vous posez la question, oui je suis tatoué Apple
SGBD
----
Les filesytems en vigueur s'appuient tous plus ou moins sur les bêtes arborescences, ce qui est très très limité. C'est une abstraction de représentation de données qui répond bien aux limitations de l'humain (quoi qu'on en trouve pour qui c'est déjà trop compliqué), mais qui n'a aucune réalité physique : le matos s'en fout, bien que ça ne soit pas évident sur non-mac (par exemple d'autres FS n'ont pas de FileID, ce qui les confine nécessairement aux notions primitives de chemin d'accès et structure arborescente, c'est-à-dire qu'ils ont transformé en limitations techniques concrètes des choix fonctionnels abstraits, avec pour conséquence que les OS eux-mêmes intègrent ces limitations comme des lois de la nature, bref pas d'alias sur PC).
Certains FS compensent de diverses façons en ajoutant des meta-données, ou en les stockant dans un SGBD séparé plus performant, ou en ajoutant un niveau de complexité au FS (fichiers à 2 branches en HFS dont l'une gérée comme un SGBD par l'OS, FS multi-branches dans NT dont l'intérêt reste à exploiter alors que ça leur aurait presque permis les bundles de Mac OS X -- si ce n'est qu'une des raisons des bundles est de survivre aussi à des FS vraiment plats).
Mais ça reste du caca comparé à un vrai SGBD. En gros dans une base de données il n'y a ni arborescence ni distinction entre les types de données. Rien n'empêche un enregistrement d'être lié à plusieurs contextes et le contenu d'un fichier a le même statut que ses meta-infos: pas de différence par exemple entre chercher dans noms, dates, familles, versions, types, ou contenus et pas de raison de ne pas trouver "bite" dans "trou" parce que tu l'as rangé dans "poil". Sans aller jusque là, M$ travaille à faire passer pour SGBD son futur FS, qui à ma connaissance ne sera que l'ajout d'une couche SGBD séparée en plus de données plates traditionnelles (en espérant mieux que Joliet qui en séparant les couches d'ancien et nouveau avait l'immense avantage de pouvoir zaper les noms longs en cas de problème -- c'est arrivé à mon frère à l'époque de W95, peut-être pour d'autres raisons ressemblant à ce qui nous arrive quand on fait passer du HFS+ à travers une couche trop primitive pour unicode et 256 chars, comme AppleShare pre-X --, et en espérant mieux que les commentaires pre-X, qui sont stockés avec d'autres trucs séparément du FS et ont longtemps disparu aux reconstructions de la BDD "Desktop", elles-mêmes rendues nécessaires par les désynchronisations dues à cette dissociation).
Apple discrétos
---------------
Comme tu sais ils ont embauché un Be peu avant d'ajouter la journalisation, qui était l'une des caractéristiques de BeOS (nixe le risque de désynchronisations structurelles). L'autre caractéristique du FS de Be était le SGBD à meta-données de la mort.
http://www.rebolfrance.net/articles/beos/beos_database.pdf(...)
Actuellement les mises à jour X convergent doucement vers ça, de façon visible (recherche vaguement dynamique du Finder) ou non (moteur d'indexation et APIs de recherches), ce qui pourrait préparer une base fonctionnelle avant un saut technique (faire entrer doucement les pignoufs et leur servir des consos en attendant le moment de les coller au mur en allumant les 12 KW, le dance floor et la boule à paillettes).
10 ans de retard
----------------
Fonctionnellement les avantages potentiels sont Kaulossaux, comme Copland et BeOS en donnaient déjà un aperçu :
Quelque chose comme les smart playlists d'iTunes -- stocker une recherche en gros comme un "dossier dynamique" sans rapport particulier avec l'éventuelle structure hiérarchique. (en étant vraiment velu je pourrais scripter les actions de dossiers pour émuler ce genre de fonctionnalité, mais ça resterait du bricolage limité par l'obligation de déplacer les trucs ou en faire des alias ; sous ouin n'en parlons pas, ni actions de dossiers ni alias)
Meta-données en liberté -- dans BeOS les fichiers ne sont pas juste des zones de la surface du disque associées à des noms quelque part dans l'arborescence et quelques autres détails prévus comme dates et versions, mais aussi tout autre information associée librement, avec le même statut, de même que tout fichier mac peut contenir tout type de meta-donnée dans la branche ressource, si ce n'est que le ressource manager est distinct, loin au-dessus du FS, et trop limité pour être attaqué transversalement (il gère les ressources des quelques 10aines ou 100aines de fichiers ouverts mais éclate à quelques 10aines de milliers de ressources et quelques 10aines de Megs, pas assez pour gérer tous les fichiers d'un volume). Par exemple il y a sous BeOS des trucs ressemblant à MP3Rage qui créent des champs de meta-données à partir des tags ID3, à la différéence qu'un mac n'en fait pas grand chose une fois qu'elles sont dans les quelques champs fixés d'avance - noms (filesystem), versions (resources), ou commentaires (desktop DB), et pratiquement rien s'il nous prenait de créer des ressources plus libres que ça (comme ressources ANPA/IPTC utilisés par ToShop, GraphicConverter et les catalogueurs mais ignorées par le Finder et tout le reste), alors que BeOS en fait tout ce que tu n'oses imaginer (attributs créés pour l'occasion, sans limite de taille, recherches de fou, mais aussi rien n'oblige à présenter les fichiers par leurs noms : le Tracker de BeOS peut très bien n'afficher que telle ou telle autre meta-donnée). Pour des MP3 l'usage est évident: mettre les tags dans des attributs du FS et se passer des noms de fichiers.
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par _alex . Évalué à 2.
pourquoi ne pas implémenter le FS comme une base de données, au lieu d'avoir un FS traditionnel et une base de données qui doivent rester synchronisés ?
Quand je vois procfs et les autres sous linux, je me dis que ca doit être assez simple après de proposé un système en arborescence pour le noyau avec derrière une base de données. Rien n'empêche après, avec une API spécialisée, de faire des requêtes type SQL. Et les dossiers virtuels représentant le résultat d'une requête sont accessible...
Avantage : pas de stockage d'une base de données qui est elle même un ou plusieurs fichiers du filesystem et qui doit synchronisée...
Inconvénient : le filesystem n'est plus compatible (je vois pas ca comme un problème).
Oui, il reste le problème de l'indexation, mais la encors si c'est proposé au niveau du FS et non pas comme une surcouche, j'ai l'impression que c'est plus simple.
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par thaodalf . Évalué à 1.
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par Aldoo . Évalué à 2.
Il me semble qu'il n'y ait pas de probléme incontournable ;-)
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par bobert . Évalué à 2.
J'ai l'impression que le monde des LL a fait une réaction épidermique à la base de registres de Windows. Depuis, on a traîné dans la boue ceux qui proposaient une interface unifiée de stockage de données de configuration dans des bases de données-fichier (ça va pas, non ? Tout doit prendre la forme de fichiers "plats", qu'on puisse modifier à la main!).
Alors une base de données comme système de données, tu n'y penses même pas !! (Enfin pour ma part j'attends ça avec impatience...)
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par zorel . Évalué à 2.
Pour ton second paragraphe, expliqué comme ça (une BDD et les vues), certes c'est intéressant. Mais ce qui me fait un peu peur, c'est la complexité du truc: plus un «machin» est compliqué, plus il a de risque de planter, mal se comporter ou que sais-je encore. «La perfection est atteinte non pas quand il n'y a plus rien a rajouter, mais quand il n'y a plus rien a enlever». Reste a savoir quels sont les composants et les fonctionnalités strictement nécessaires, mais à mon avis, ça doit être assez lourd pour avoir une simili base de données comme système de gestion de fichiers.
Enfin, on verra peut-être bien ce que ça donnera sur MacOSX, Longhorn ou un jour Linux et les *BSD. En attendant, je suis séduit par la théorie, mais j'ai des craintes sur la pratique.
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par _alex . Évalué à 1.
Donc pas de truc style base de registres qui est un ou deux fichiers sur un FS.
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par gnujsa . Évalué à 2.
Tu pourrai indiquer tes sources ;-)
$ epiphany about:epiphany
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par Jimmy . Évalué à 3.
Sin je ne m'abuse, c'est une citation d'Antoine de St Exupéry.
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par jmfayard . Évalué à 3.
Mais tu t´en sors encore mieux avec des applications specialisees et intègrèes pour une tache : gère tes milliers de photos avec KimDaBa, gère tes milliers de morceaux de musiques avec iTunes/Rhythmbox/Amarok ou autre, gère tes vidèos (Oh non, là il faut pas abuser, tu n´en as pas tant que ca, ou alors attends-toi à une visite de la MPAA)
Voila, là tu trouveras facilement et rapidement ton document sur le disque.
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par dommtp . Évalué à 2.
C'est tellement mieux si tu a une couche commune bas niveau (pas ex le FS) qui gere ca pour toi.
En plus tu peux tres bien avoir envie de faire des recherches inter-média, par exemple tu peux avoir envie de trouver tous les films, toutes les chanson et tous les articles sur tel artiste. Ou encore rechercher dans tes photos et tes films de vacances toutes les apparitions de telle autre personne. Avec ton i-tune, tu vas avoir du mal...
Autre avantage a gérer l'indexation de facon unifiée, si par exemple tu gères comme moi ta vidéothèeque avec videoDB, le jour ou tu as envie de changer d'outil parce que tu en a trouvé un mieux, tu sera obligé de re-saisir toutes les informations de chaque film parce qu'elles sont gérées par l'appli dans son format propre au lieu d'etre gérées de facon standard par le FS.
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par Thomas Droz . Évalué à 1.
c'est libre et ça existe DEJA le 30 juin 2004....
mes 2c, mais j'ai peut etre rien compris...
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par peau chat . Évalué à 2.
Reiser reste un systeme hiérarchique.
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par Christophe Merlet (site web personnel) . Évalué à 3.
Ce n'est pour l'instant qu'un vaporware qui ne sera meme pas intégér à longhorn selon les derniers dires de la firme de redmond. Et longhorn c'est pas avant 2006 !
WinFS n'a rien de révolutionnaire en soit. Le problème lié a un système de fichiers qui serait une base de données ou qui aurait juste une base de données associés est un problème de performance.
Imaginez que chaque écriture sur disque nécessite l'indexation plein texte du nouveau fichier et de tous ces attributs. ça boufferai un max de cpu.
Imaginez que voux décompressez un tar.bz2 des sources du noyau, chacun des milliers de fichiers devra être indexé en plein texte dans la base de données du système au lieu d'être simplement copié bit à bit sur le disque dur. Aujourd'hui avec les processeurs actuells, ça prendrait 1 heure à décompresser son noyau. En 2010 avec les processeurs de l'époque tournant à 75 GHz et des RAM de 10 Go ça sera immédiat.
Un système de fichiers sous forme de base de données ne sera pas une évolution mais une conséquence logique de l'augmentation de la puissance des machines ni plus ni moins.
Par ailleurs, une indexation correcte de tout type de fichiers est pour l'instant une belle utopie. Comment voulez-vous que votre musique, vos vidéos, vos photos soit correctement indéxé si vous n'avez pas pris la peine de renseigner correctement, avec patience pendant des heures, les meta tags manuellement ?
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par xylpho . Évalué à 2.
Manuellement?
Mon Dieu quelle horreur
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par gnujsa . Évalué à 4.
Mon Dieu quelle horreur »
Et bien dans certains cas, ça reste difficile de faire autrement. Example, les photos: Il y a bien les données techniques EXIF, mais c'est pas super interessant de faire des recherches de toutes ses photos prisent au 1/60 sec. avec une sensibilitée de 400 ISO ;-)
Sans renseigner manuellement des meta-données comme sujet, lieu de prise de vues, etc.. , je vois pas trop l'interet d'une base de donnée.
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par xylpho . Évalué à 1.
Bien ententu il ne s'agit pas de soft gratuit mais ça marche. Au pire, un applescript bien foutu peut résoudre ce genre de casse tête.
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par ArBaDaCarBa . Évalué à 4.
http://maccentral.macworld.com/news/2004/06/29/konfabulator/(...)
http://www.konfabulator.com/(...)
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par zerchove . Évalué à 0.
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par xylpho . Évalué à 1.
Mpfff
Konfabulator n'a pas inventé le "widget" si je me rappelle bien.
Sinon ils peuvent s'en prendre à Panic avec http://panic.com/stattoo/(...) ou bien à Karamba et tous les autres méchants qui ont le culot de faire des "widgets".
Ce serait un rip-off de Konfabulator si Dashboard reposait sur la même architecture, mais ce n'est même pas le cas.
Lire http://apple.weblogsinc.com/entry/3510628962883717/(...) pour mieux comprendre
# c bien bo tous les trucs de geeks (reiserfs vs befs etc )
Posté par - - . Évalué à 9.
tout cela est bien bo et tres intelligent, technique , utile et tout mais ca se résume PAS QUE A CELA!!
apple est le premier à dévoiler une solution COMPLETE et UTILISABLE par tous (avec l'interface, avec un sdk pour dévelopeurs, avec une architecture précise, de la tete au pied, plugins, etc etc )
et ca va bien au dela de simplement dire "ho ben des meta data, c vieux comme le monde hahaha, moa j'avais beos"
sinon, je change de sujet , pour dire que le monde "open source" ne fait pas que de se palucher en attendant les apple et les crosoft :
le projet Gnome Storage qui a été commencé et réfléchit depuis pratiquement 10 mois est conceptuellement la même chose que spotlight.
et c'est achement plus dur que de se dire "super ,ds befs on peut foutre plein de metadata a un tas d'octets d'un fichier"
il faut réfléchir à l'indexation! quand va t'on mettre à jour l'index ? que va t'on indexer ? comment on etend le systeme a de nouvelles données et meta info ? comment faire ca de manière performante ? comment l'utilisateur va interagir avec? que va utiliser le développeur ? en quel langage faire ca ? quelle technologie de base va t'on utiliser ? doit on se reposer sur un obscure file system et le rendre obligatoire ? doit on re-implementer tout un sgbd par dessus un systeme de fs classique ?
etc etc etc
allez voir :
beagle : http://www.gnome.org/projects/beagle/(...)
dashboard : http://www.nat.org/dashboard/(...)
gnome-storage : ici un article qui résume l'état http://www.gnome.org/~seth/blog//storage-speaking-notes(...)
ici, vous pouvez voir une photo des travaux pour Gnome : http://blogs.sun.com/roller/page/jhy/20040628(...)
et bé vi, gnome a pas attendu apple
je vais meme dire mieux :
microsoft a attendu personne
Apple a pas attendu gnome
etc
parce que tout simplement ce genre d'idées vient NATURELLEMENT avec l'évolution des besoins et de la puissance de stockage et de calcul des ordinateurs
merci, de vous tenir au courant de tout ce qui se passe si vous voulez débattre de "ouiiin ouiiiiin le monde proprio copie l'opensource qui copie le monde proprio qui copie...."
[^] # Re: c bien bo tous les trucs de geeks (reiserfs vs befs etc )
Posté par Gilles Crebassa . Évalué à 2.
[^] # Re: c bien bo tous les trucs de geeks (reiserfs vs befs etc )
Posté par bobert . Évalué à 2.
Enfin, j'en étais déjà là il y a deux ans (http://linuxfr.org/comments/137786,1.html(...))... tout ça nous rajeunit pas...
[^] # Re: c bien bo tous les trucs de geeks (reiserfs vs befs etc )
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 3.
Aujourd'hui, si je fais une recherche sous Linux pour trouver un fichier, je mets des plombes. Sous BeOS, je mettais 1s. Oui, BeOS, le Tracker associé au BeFS, étaient formidable. Il n'y a que dans le monde conservateur (ceux qui ne veulent pas voir évoluer la norme, et rester fidèle à des manières de faire d'il y a 30 ans) de certaines communautés Linux et BSD que les systèmes de fichiers sont à peine journalisés.
Pour preuve, le projet SkyOS, qui a adapté le BeFS en SkyFS, et inventé une base de registre propre.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.