Au hasard de la promenade dans les nouvelles fonctionnalités de Lion,
trois liens qui me semblent intéressants et méritent sans doute
approfondissement :
1/ le prix de la version serveur (sans limitations ?)
<http://www.apple.com/fr/macosx/server/>
2/ le Per-user screen sharing qui romprait avec l'utilisation de Mac OSX
uniquement "en avant plan" (si je comprends bien)
<http://www.apple.com/fr/macosx/whats-new/features.html#screensharing>
3/ les solutions de restauration sur partition dédiée ou depuis un
backup TimeMachine (et pas seulement en ligne)
<http://www.apple.com/fr/macosx/whats-new/features.html#internetrestore>
(pour répondre aux inquiétudes de notre ami)
Il semble qu'il y ait pas mal d'autres bonnes choses à découvrir
> > XML est bien... pour certaines choses... lorsqu'il est bien utilisé. > > Le format XML des plist est une connerie sans nom conçu par des > personnes qui ne savent pas à quoi XML est utile (mis à part l'effet de > mode). Ce format n'amène aucun des intérêts de XML et ne fait que > complexifier les choses. Quitte à utiliser un éditeur GUI autant revenir > aux ressources d'antan qui étaient bien plus puissantes ! >
Voilà, c'est exactement ce que je pense.
Quand les balises occupent 90% du fichier XML et le contenu seulement 10% (ce qui est le cas des plist), on peut raisonnement se demander si XML est un bon choix.
il me semble que la taille minimum d'un fichier stockable sur disque dur est de 512 octets, on perd quand même de la place sans les balise finalement, et puis une balise de 512 octets j'ai jamais vu ça...
>
> XML est bien... pour certaines choses... lorsqu'il est bien utilisé.
>
> Le format XML des plist est une connerie sans nom conçu par des
> personnes qui ne savent pas à quoi XML est utile (mis à part l'effet de
> mode). Ce format n'amène aucun des intérêts de XML et ne fait que
> complexifier les choses. Quitte à utiliser un éditeur GUI autant revenir
> aux ressources d'antan qui étaient bien plus puissantes !
>
Voilà, c'est exactement ce que je pense.
Quand les balises occupent 90% du fichier XML et le contenu seulement
10% (ce qui est le cas des plist), on peut raisonnement se demander si
XML est un bon choix.
il me semble que la taille minimum d'un fichier stockable sur disque dur
est de 512 octets, on perd quand même de la place sans les balise
finalement, et puis une balise de 512 octets j'ai jamais vu ça...
> > XML est bien... pour certaines choses... lorsqu'il est bien utilisé. > > Le format XML des plist est une connerie sans nom conçu par des > personnes qui ne savent pas à quoi XML est utile (mis à part l'effet de > mode). Ce format n'amène aucun des intérêts de XML et ne fait que > complexifier les choses. Quitte à utiliser un éditeur GUI autant revenir > aux ressources d'antan qui étaient bien plus puissantes ! >
Voilà, c'est exactement ce que je pense.
Quand les balises occupent 90% du fichier XML et le contenu seulement 10% (ce qui est le cas des plist), on peut raisonnement se demander si XML est un bon choix.
il me semble que la taille minimum d'un fichier stockable sur disque dur est de 512 octets, on perd quand même de la place sans les balise finalement, et puis une balise de 512 octets j'ai jamais vu ça...
Quand les balises occupent 90% du fichier XML et le contenu seulement 10% (ce qui est le cas des plist), on peut raisonnement se demander si XML est un bon choix.
il me semble que la taille minimum d'un fichier stockable sur disque dur est de 512 octets, on perd quand même de la place sans les balise finalement, et puis une balise de 512 octets j'ai jamais vu ça...
La place n'est pas le problème.
-- pehache
Le 30/06/11 23:51, Dieu a écrit :
Quand les balises occupent 90% du fichier XML et le contenu seulement
10% (ce qui est le cas des plist), on peut raisonnement se demander si
XML est un bon choix.
il me semble que la taille minimum d'un fichier stockable sur disque dur
est de 512 octets, on perd quand même de la place sans les balise
finalement, et puis une balise de 512 octets j'ai jamais vu ça...
Quand les balises occupent 90% du fichier XML et le contenu seulement 10% (ce qui est le cas des plist), on peut raisonnement se demander si XML est un bon choix.
il me semble que la taille minimum d'un fichier stockable sur disque dur est de 512 octets, on perd quand même de la place sans les balise finalement, et puis une balise de 512 octets j'ai jamais vu ça...
La place n'est pas le problème.
-- pehache
dieupurre
pehache wrote:
Le 30/06/11 23:51, Dieu a écrit :
>> >> Quand les balises occupent 90% du fichier XML et le contenu seulement >> 10% (ce qui est le cas des plist), on peut raisonnement se demander si >> XML est un bon choix. > > il me semble que la taille minimum d'un fichier stockable sur disque dur > est de 512 octets, on perd quand même de la place sans les balise > finalement, et puis une balise de 512 octets j'ai jamais vu ça... >
>>
>> Quand les balises occupent 90% du fichier XML et le contenu seulement
>> 10% (ce qui est le cas des plist), on peut raisonnement se demander si
>> XML est un bon choix.
>
> il me semble que la taille minimum d'un fichier stockable sur disque dur
> est de 512 octets, on perd quand même de la place sans les balise
> finalement, et puis une balise de 512 octets j'ai jamais vu ça...
>
>> >> Quand les balises occupent 90% du fichier XML et le contenu seulement >> 10% (ce qui est le cas des plist), on peut raisonnement se demander si >> XML est un bon choix. > > il me semble que la taille minimum d'un fichier stockable sur disque dur > est de 512 octets, on perd quand même de la place sans les balise > finalement, et puis une balise de 512 octets j'ai jamais vu ça... >
In article <1k3p14u.1plmpxc1n7yax0N%, (FiLH) wrote:
> Euhhhhhhhh! non :-) > Ne pas commenter, c'était la sécurité de l'emploi.
Commenter ne sert à rien : au bout de deux ans, le code a évolué, les commentaires non.
La seule bonne façon de faire : écrire du code auto-commenté , avoir des noms de fonctions et de variables qui sont humainement et simplement compréhensibles.
+1 Les commentaires c'est dangereux C'est le code qui doit être lisible
Je regardais hier soir un podcast d'un cours d'informatique du MIT; le prof parle debugging et dit "assurez vous que le code que vous avez dans l'éditeur est bien celui que vous faites tourner" (genre je n'ai pas encore enregistré). Les commentaires c'est pas le code. -- Francois
In article <1k3p14u.1plmpxc1n7yax0N%filh@filh.orgie>,
filh@filh.orgie (FiLH) wrote:
> Euhhhhhhhh! non :-)
> Ne pas commenter, c'était la sécurité de l'emploi.
Commenter ne sert à rien : au bout de deux ans, le code a évolué, les
commentaires non.
La seule bonne façon de faire : écrire du code auto-commenté , avoir des
noms de fonctions et de variables qui sont humainement et simplement
compréhensibles.
+1
Les commentaires c'est dangereux
C'est le code qui doit être lisible
Je regardais hier soir un podcast d'un cours d'informatique du MIT; le
prof parle debugging et dit "assurez vous que le code que vous avez dans
l'éditeur est bien celui que vous faites tourner" (genre je n'ai pas
encore enregistré). Les commentaires c'est pas le code.
--
Francois
In article <1k3p14u.1plmpxc1n7yax0N%, (FiLH) wrote:
> Euhhhhhhhh! non :-) > Ne pas commenter, c'était la sécurité de l'emploi.
Commenter ne sert à rien : au bout de deux ans, le code a évolué, les commentaires non.
La seule bonne façon de faire : écrire du code auto-commenté , avoir des noms de fonctions et de variables qui sont humainement et simplement compréhensibles.
+1 Les commentaires c'est dangereux C'est le code qui doit être lisible
Je regardais hier soir un podcast d'un cours d'informatique du MIT; le prof parle debugging et dit "assurez vous que le code que vous avez dans l'éditeur est bien celui que vous faites tourner" (genre je n'ai pas encore enregistré). Les commentaires c'est pas le code. -- Francois
Paul Gaborit
À (at) Thu, 30 Jun 2011 21:12:11 +0200, (FiLH) écrivait (wrote):
xml permet d'exprimer des choses autrement plus puissantes, sans avoir à chaque fois à réinventer l'eau tiède d'une syntaxe plus ou moins hasardeuse, le tout gérable avec des outils standards et normalisés.
C'est tout à fait vrai de XML... Mais certainement pas du format plist !
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Thu, 30 Jun 2011 21:12:11 +0200,
filh@filh.orgie (FiLH) écrivait (wrote):
xml permet d'exprimer des choses autrement plus puissantes, sans avoir à
chaque fois à réinventer l'eau tiède d'une syntaxe plus ou moins
hasardeuse, le tout gérable avec des outils standards et normalisés.
C'est tout à fait vrai de XML... Mais certainement pas du format plist !
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Thu, 30 Jun 2011 21:12:11 +0200, (FiLH) écrivait (wrote):
xml permet d'exprimer des choses autrement plus puissantes, sans avoir à chaque fois à réinventer l'eau tiède d'une syntaxe plus ou moins hasardeuse, le tout gérable avec des outils standards et normalisés.
C'est tout à fait vrai de XML... Mais certainement pas du format plist !
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Paul Gaborit
À (at) Thu, 30 Jun 2011 21:12:10 +0200, (FiLH) écrivait (wrote):
Il y a des éditeurs qui font le boulot, et quand la DTD est bien écrite, ça permet de vérifier les choses, ce que l'on ne peut pas faire avec les multiples syntaxe fantaisistes des fichiers plats.
Le problème des plist est bien là : la DTD ou le schéma ne fait que décrire génériquement le contenu du fichier plist. Il n'aide en rien à structurer ou à vérifier le contenu par rapport à son usage. C'est un sous-format générique non modulable construit via le format générique modulable qu'est XML.
Je ne dis pas que c'était mieux avant. Je dis juste que XML est largement sous-exploité (donc mal exploité) dans le format plist qui est bien trop générique.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Thu, 30 Jun 2011 21:12:10 +0200,
filh@filh.orgie (FiLH) écrivait (wrote):
Il y a des éditeurs qui font le boulot, et quand la DTD est bien écrite,
ça permet de vérifier les choses, ce que l'on ne peut pas faire avec les
multiples syntaxe fantaisistes des fichiers plats.
Le problème des plist est bien là : la DTD ou le schéma ne fait que
décrire génériquement le contenu du fichier plist. Il n'aide en rien à
structurer ou à vérifier le contenu par rapport à son usage. C'est un
sous-format générique non modulable construit via le format générique
modulable qu'est XML.
Je ne dis pas que c'était mieux avant. Je dis juste que XML est
largement sous-exploité (donc mal exploité) dans le format plist qui est
bien trop générique.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Thu, 30 Jun 2011 21:12:10 +0200, (FiLH) écrivait (wrote):
Il y a des éditeurs qui font le boulot, et quand la DTD est bien écrite, ça permet de vérifier les choses, ce que l'on ne peut pas faire avec les multiples syntaxe fantaisistes des fichiers plats.
Le problème des plist est bien là : la DTD ou le schéma ne fait que décrire génériquement le contenu du fichier plist. Il n'aide en rien à structurer ou à vérifier le contenu par rapport à son usage. C'est un sous-format générique non modulable construit via le format générique modulable qu'est XML.
Je ne dis pas que c'était mieux avant. Je dis juste que XML est largement sous-exploité (donc mal exploité) dans le format plist qui est bien trop générique.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
mloiseau
Paul Gaborit wrote:
À moins que Apple ne fournisse aussi le disque externe pour héberger cette "built-in restore partition"... mais, à ma connaissance, ce n'est pas inclus dans le prix ! ;-)
Et sans doute pas téléchargeable sur le Mac App Store. Ou alors, là, je dis chapeau. -- Un blog inutile et passablement nuisible aux neurones http://mloiseau.free.fr/blog/
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
À moins que Apple ne fournisse aussi le disque externe pour héberger
cette "built-in restore partition"... mais, à ma connaissance, ce n'est
pas inclus dans le prix ! ;-)
Et sans doute pas téléchargeable sur le Mac App Store. Ou alors, là, je
dis chapeau.
--
Un blog inutile et passablement nuisible aux neurones
http://mloiseau.free.fr/blog/
À moins que Apple ne fournisse aussi le disque externe pour héberger cette "built-in restore partition"... mais, à ma connaissance, ce n'est pas inclus dans le prix ! ;-)
Et sans doute pas téléchargeable sur le Mac App Store. Ou alors, là, je dis chapeau. -- Un blog inutile et passablement nuisible aux neurones http://mloiseau.free.fr/blog/
J.P
In article <4e0d5eee$0$3945$, Francois wrote:
In article <1k3p14u.1plmpxc1n7yax0N%, (FiLH) wrote:
> > Euhhhhhhhh! non :-) > > Ne pas commenter, c'était la sécurité de l'emploi. > > Commenter ne sert à rien : au bout de deux ans, le code a évolué, les > commentaires non. > > La seule bonne façon de faire : écrire du code auto-commenté , avoir des > noms de fonctions et de variables qui sont humainement et simplement > compréhensibles.
+1 Les commentaires c'est dangereux C'est le code qui doit être lisible
Je regardais hier soir un podcast d'un cours d'informatique du MIT; le prof parle debugging et dit "assurez vous que le code que vous avez dans l'éditeur est bien celui que vous faites tourner" (genre je n'ai pas encore enregistré). Les commentaires c'est pas le code.
C'est très con, mais autrefois, j'enseignais à mes étudiants de comencer à écrire les commentaires en pensant au code et ensuite de mettre le code en face. Vieux restes des sources de RT11 de DEC où on pouvait lire le fonctionnement de la chose dans les commentaires. Le code n'étant que la "traduction" pour la machine. Mais c'est très très vieux, très très con !
Les fonctions dûment nommées avec 10 paramètres derrière, je n'ai jamais pu lire :-(
-- Jean-Pierre
In article <4e0d5eee$0$3945$426a34cc@news.free.fr>,
Francois <Francois@invalid.invalid> wrote:
In article <1k3p14u.1plmpxc1n7yax0N%filh@filh.orgie>,
filh@filh.orgie (FiLH) wrote:
> > Euhhhhhhhh! non :-)
> > Ne pas commenter, c'était la sécurité de l'emploi.
>
> Commenter ne sert à rien : au bout de deux ans, le code a évolué, les
> commentaires non.
>
> La seule bonne façon de faire : écrire du code auto-commenté , avoir des
> noms de fonctions et de variables qui sont humainement et simplement
> compréhensibles.
+1
Les commentaires c'est dangereux
C'est le code qui doit être lisible
Je regardais hier soir un podcast d'un cours d'informatique du MIT; le
prof parle debugging et dit "assurez vous que le code que vous avez dans
l'éditeur est bien celui que vous faites tourner" (genre je n'ai pas
encore enregistré). Les commentaires c'est pas le code.
C'est très con, mais autrefois, j'enseignais à mes étudiants de comencer à
écrire les commentaires en pensant au code et ensuite de mettre le code en face.
Vieux restes des sources de RT11 de DEC où on pouvait lire le fonctionnement de
la chose dans les commentaires. Le code n'étant que la "traduction" pour la
machine.
Mais c'est très très vieux, très très con !
Les fonctions dûment nommées avec 10 paramètres derrière, je n'ai jamais pu lire
:-(
In article <1k3p14u.1plmpxc1n7yax0N%, (FiLH) wrote:
> > Euhhhhhhhh! non :-) > > Ne pas commenter, c'était la sécurité de l'emploi. > > Commenter ne sert à rien : au bout de deux ans, le code a évolué, les > commentaires non. > > La seule bonne façon de faire : écrire du code auto-commenté , avoir des > noms de fonctions et de variables qui sont humainement et simplement > compréhensibles.
+1 Les commentaires c'est dangereux C'est le code qui doit être lisible
Je regardais hier soir un podcast d'un cours d'informatique du MIT; le prof parle debugging et dit "assurez vous que le code que vous avez dans l'éditeur est bien celui que vous faites tourner" (genre je n'ai pas encore enregistré). Les commentaires c'est pas le code.
C'est très con, mais autrefois, j'enseignais à mes étudiants de comencer à écrire les commentaires en pensant au code et ensuite de mettre le code en face. Vieux restes des sources de RT11 de DEC où on pouvait lire le fonctionnement de la chose dans les commentaires. Le code n'étant que la "traduction" pour la machine. Mais c'est très très vieux, très très con !
Les fonctions dûment nommées avec 10 paramètres derrière, je n'ai jamais pu lire :-(
-- Jean-Pierre
pehache
Le 01/07/11 04:19, Dieu a écrit :
La place n'est pas le problème.
Mais alors ou est le problème ? ;-D
En résumé, des fichiers imbitables à lire et mortels à remplir, là où une fstab est d'une grande simplicité.
-- pehache
Le 01/07/11 04:19, Dieu a écrit :
La place n'est pas le problème.
Mais alors ou est le problème ? ;-D
En résumé, des fichiers imbitables à lire et mortels à remplir, là où
une fstab est d'une grande simplicité.
En résumé, des fichiers imbitables à lire et mortels à remplir, là où une fstab est d'une grande simplicité.
-- pehache
filh
Xavier wrote:
FiLH wrote:
> qui n'a rien de nouveau, cela s'appelle du lisp est ça date des années > 50/60 :)
Horresco referens !
Tss tss : plus le temps avance, et plus les différents langages intègrent des choses qui existaient déjà dans le lisp.
- gargage collector, c'était honni, mais bon, Java, javascript, yen a - fermetures : Apple en utilise, et à proposé une extension au C, php 6 en aura - fonctions du premire degrès, ben, php, javascript, - en java on a des techniques de programmations qui se rappochent beaucoup (sans le dire hein) de ce qu'on faisait en lisp...
FiLH qui se marre.
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Xavier <xavier@groumpf.org> wrote:
FiLH <filh@filh.orgie> wrote:
> qui n'a rien de nouveau, cela s'appelle du lisp est ça date des années
> 50/60 :)
Horresco referens !
Tss tss : plus le temps avance, et plus les différents langages
intègrent des choses qui existaient déjà dans le lisp.
- gargage collector, c'était honni, mais bon, Java, javascript, yen a
- fermetures : Apple en utilise, et à proposé une extension au C, php 6
en aura
- fonctions du premire degrès, ben, php, javascript,
- en java on a des techniques de programmations qui se rappochent
beaucoup (sans le dire hein) de ce qu'on faisait en lisp...
FiLH qui se marre.
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
> qui n'a rien de nouveau, cela s'appelle du lisp est ça date des années > 50/60 :)
Horresco referens !
Tss tss : plus le temps avance, et plus les différents langages intègrent des choses qui existaient déjà dans le lisp.
- gargage collector, c'était honni, mais bon, Java, javascript, yen a - fermetures : Apple en utilise, et à proposé une extension au C, php 6 en aura - fonctions du premire degrès, ben, php, javascript, - en java on a des techniques de programmations qui se rappochent beaucoup (sans le dire hein) de ce qu'on faisait en lisp...
FiLH qui se marre.
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
