Linux? - Page 139

Apple donne l'illusion que ça marche sous OS X, mais leur système est bâtard et trompeur, une application est un fichier, mais elle est visualisée comme un dossier, et quand l'utilisateur croit opérer sur un dossier, ça fait plein de trucs cachés en interne. Je ne l'ai vu nulle part ailleurs. (Même sur un certain autre système d'exploitation propriétaire, supprimer le dossier d'une application ne supprimera pas les entrées de menu etc.)

Ce n'est pas possible proprement avec une architecture propre comme celle de GNU/Linux. (Par exemple, supprimer un dossier doit pouvoir se faire par rm -rf ou par n'importe quel gestionnaire de fichiers, pas seulement par un gestionnaire de fichiers "magique" qui fait plein de trucs derrière ton dos!)

sauf que l'utilisateur lambda préfèrera un outil "magique" par rapport à un rm -rf

rm -rf peut être vachement magique des fois, j'ai essayé

./4141 > Heu… T'as rien compris au film toi…
Déjà d'une part je ne fais nullement référence à Apple. Sur n'importe quel système il est possible de recevoir des notifications de création/supression/modification de fichier/dossier, et/ou de mettre en place un mécanisme de détection et d'enregistrement automatique des applications. (Il y a juste quelques règles à définir et à respecter…)
D'autre part, une application OSX est un exécutable, dans un bundle (c'est pas un package au sens où tu l'entends…) qui est un dossier, représenté comme un fichier (et non l'inverse).
Encore d'autre part, à part masquer (légèrement) le fait que le bundle soit un dossier et te l'afficher comme un dossier le gestionnaire de fichiers "magique" () qu'est le Finder ne fait absolument rien de magique dans ton dos…
Encore d'autre part, ce dossier (bundle) peut parfaitement être copié avec cp -r, déplacé avec mv, ou supprimé avec rm -rf.

Pour finir, je ne vois absolument pas pourquoi il faudrait absolument OMG c'est hyper super ultra méga giga indispensable OMG OMG que ce fichier puisse être supprimé avec rm -rf !!! … .
Si tu veux niquer ton système t'as toujours eu la possibilité d'effacer n'importe quel fichier à l'arrache quand tu veux sur n'importe quel système installé sur un support RW. C'est parfois (très) difficile mais c'est toujours possible.
En dehors de ça, tu peux très bien définir un truc propre où l'utilisateur n'a pas à foutre son nez et puis basta…
Tu sais, on développe des outils pour ça en général. Suffit de pas développer des outils bogués…

Kevin Kofler (./4141) :
Apple donne l'illusion que ça marche sous OS X, mais leur système est bâtard et trompeur, une application est un fichier, mais elle est visualisée comme un dossier, et quand l'utilisateur croit opérer sur un dossier, ça fait plein de trucs cachés en interne. Je ne l'ai vu nulle part ailleurs. (Même sur un certain autre système d'exploitation propriétaire, supprimer le dossier d'une application ne supprimera pas les entrées de menu etc.)

Tu ne devrais vraiment pas parler de ce que tu ne connais pas

Ce n'est pas possible proprement avec une architecture propre comme celle de GNU/Linux. (Par exemple, supprimer un dossier doit pouvoir se faire par rm -rf ou par n'importe quel gestionnaire de fichiers, pas seulement par un gestionnaire de fichiers "magique" qui fait plein de trucs derrière ton dos!)

Bin, ça tombe bien, tu peux le faire. Où est le problème ?

En fait, si tu n'aimes pas OS X, c'est simplement parce que tu ne sais pas comment ça fonctionne…

J'arrive après la guerre, et c'est peut être la faute à mon post pas assez détaillé.
L'application peut être supprimée via un rm -rf (et heureusement), et comme le dit GC il est tout à fait possible pour le système "d'observer" les fichiers. C'est en général dangereux (les modifications pouvant être faites offline…) mais c'est possible. Il peut très bien faire un scan des packages au démarrage aussi, après tout ce n'est qu'une liste de programmes et il a bien le droit de savoir de quoi il dispose. C'est plus lent mais ça évite les références cassées et autres trucs fâcheux.
Je ne promeus pas ce système comme étant une solution à tout, mais ça a des mérites en tous cas, et de constat pratique c'est assez valable. Sous Windows pareil, il faut juste accepter que le système s'alourdisse avec le temps, mais sinon ça marche vraiment bien. On peut encore exécuter des logiciels qui ont 10 ou 15 ans, voire plus, si c'est pas une preuve de robustesse.

Ensuite pour le problème des mises à jour j'ai vu Folco en parler mais je crois que ce n'est pas le seul, je pense que le but chez Canonical s'ils font ça, ce n'est pas de juste de tout passer en dépendance statique (ou alors ils vont droit dans le mur). Un système qui veut se permettre d'utiliser un système d'apps autonomes doit proposer au bas-mot 99% de ce dont la plupart des apps auront besoin. Les applications se reposent alors au maximum sur les fonctions du système, et n'incluent des libs que pour certaines choses, et d'expérience en pratique justement ces choses supportent assez mal les mises à jour transparentes des libs, donc on est très souvent mieux en ne les upgradant pas (possible trou de sécurité si une faille a été découverte depuis, mais ça marche) qu'avec une app qui dysfonctionne.

Sous Linux je vois un peu moins d'utilité parce que dans le monde des bisounours tout est open-source, donc tu n'as qu'à faire ces mises à jour transparentes de libs et si une app pète tu n'as qu'à la fixer et la recompiler. De même il faut trouver une API de bureau (ça doit représenter un bon 50% de ce qu'une app fait) sinon ce n'est pas viable. Ce qui fait que j'apprécie l'introduction par Canonical de ce nouveau système c'est qu'ils ont réfléchi à une solution pour ces problèmes, et je suis intéressé de voir laquelle ce sera. Avoir une API graphique commune déjà devrait énormément aider à faire des softs bien fichus, et pas comme maintenant avoir un peu de GNOME et un peu de KDE parce que les meilleurs softs se partagent ces environnements, et ne pas pouvoir tout utiliser. Je me rappelle à l'époque il y avait un widget plasma pour avoir une barre de menus unique (à la OS X, avant que je ne découvre ce système). Elle fonctionnait bien avec les apps KDE, mais assez mal avec la plupart des apps GTK, et pas du tout avec les apps java. Résultat ce n'était pas vraiment utilisable pour moi. Dommage.

vince (./4142) :
sauf que l'utilisateur lambda préfèrera un outil "magique" par rapport à un rm -rf

Ça tombe bien, pour l'utilisateur lambda, il y a les paquetages, justement! Et du coup, l'outil "magique" s'appelle Apper.

GoldenCrystal (./4144) :
./4141 > Heu… T'as rien compris au film toi…
Déjà d'une part je ne fais nullement référence à Apple. Sur n'importe quel système il est possible de recevoir des notifications de création/supression/modification de fichier/dossier, et/ou de mettre en place un mécanisme de détection et d'enregistrement automatique des applications. (Il y a juste quelques règles à définir et à respecter…)
D'autre part, une application OSX est un exécutable, dans un bundle (c'est pas un package au sens où tu l'entends…) qui est un dossier, représenté comme un fichier (et non l'inverse).
Encore d'autre part, à part masquer (légèrement) le fait que le bundle soit un dossier et te l'afficher comme un dossier le gestionnaire de fichiers "magique" () qu'est le Finder ne fait absolument rien de magique dans ton dos…
Encore d'autre part, ce dossier (bundle) peut parfaitement être copié avec cp -r, déplacé avec mv, ou supprimé avec rm -rf.

Et les informations comme les menus, les associations de fichiers etc., elles sortent d'où? GNU/Linux, en tout cas, a besoin d'avoir ces informations dans des dossiers centraux à des endroits bien définis (qui se trouvent dans /usr et/ou dans ~), pas dans un dossier au hasard.

Quant à l'histoire des notifications, c'est un hack pourri et lent (il faut souscrire à des notifications pour tout le dossier parent qui contient les dossiers des apps et ensuite filtrer les quelques fichiers vraiment intéressants).

Pour finir, je ne vois absolument pas pourquoi il faudrait absolument OMG c'est hyper super ultra méga giga indispensable OMG OMG que ce fichier puisse être supprimé avec rm -rf !!!
… .
Si tu veux niquer ton système t'as toujours eu la possibilité d'effacer n'importe quel fichier à l'arrache quand tu veux sur n'importe quel système installé sur un support RW. C'est parfois (très) difficile mais c'est toujours possible.En dehors de ça, tu peux très bien définir un truc propre où l'utilisateur n'a pas à foutre son nez et puis basta…

Mais on l'a déjà fait, ça s'appelle "RPM"!

Tu sais, on développe des outils pour ça en général. Suffit de pas développer des outils bogués…

C'est bien pour ça qu'on développe les systèmes de paquetages et pas d'applications isolées.

Brunni (./4146) :
Sous Windows pareil, il faut juste accepter que le système s'alourdisse avec le temps, mais sinon ça marche vraiment bien.

En d'autres mots, ça marche très mal, "mais sinon ça marche vraiment bien".

Rien ne bat les paquetages style RPM en ce qui concerne la suppression de fichiers obsolètes.

Ah bon, les RPM suppriment aussi tes documents perso ?

Non, tout ce qui est dans $HOME est totalement hors de la portée de RPM (il ne va pas s'amuser à traîter tous les utilisateurs du système en boucle!), et si tu as un fichier marqué %config (généralement, ça concerne les fichiers dans /etc) et si tu l'as modifié, une version de sauvegarde (fichier .rpmsave) sera gardée à la suppression du paquetage. Mais en aucun cas tu n'auras des fichiers .so ou d'autres fichiers dans /usr qui traînent (contrairement à un certain système d'exploitation propriétaire où les anciennes DLLs s'accumulent comme la poussière).

Kevin Kofler (./4147) :
Ça tombe bien, pour l'utilisateur lambda, il y a les paquetages, justement! Et du coup, l'outil "magique" s'appelle Apper.

Apper fait donc des choses derrière ton dos!

Apper résout les dépendances, te donne (en mode paquetages, le mode normal – je ne connais pas le mode "applications" parce qu'il n'y a pas les métadonnées pour ça dans Fedora) la liste de ce qu'il va installer comme dépendances (il y a une case "ne plus demander" si tu n'en as vraiment rien à battre) et puis installe les paquetages avec RPM, il n'y a rien de caché, et surtout il t'indique clairement qu'il s'agit d'une installation, pas d'une simple copie de fichiers.

ben, si j'ai bien compris, les installations osx n'installent pas de dépendances, je ne vois pas ce qu'il y a de plus caché qu'avec une "installation de paquetages avec RPM". C'est obscur pour moi une "installation de paquetages avec RPM". Je n'ai pas la moindre idée de l'endroit où il modifie mon disque dur (enfin si, un peu, mais je n'ai pas du tout une liste exhaustive en tête)
Il est possible que tu le saches, mais c'est tout aussi caché que n'importe quelle installation.

Pen^2 (./4153) :
e n'ai pas la moindre idée de l'endroit où il modifie mon disque dur (enfin si, un peu, mais je n'ai pas du tout une liste exhaustive en tête)

Ca tombe bien, un gestionnaire comme Synaptic te donne la liste complète des fichiers installés, et à quel endroit
(et aussi le changelolg, un screenshot et autres accessoires )

Ah ?

ahah, je vois qu'on critique, on critique, mais on connais pas hein ?

ben écoute je ne sais pas, mais j'ai déjà utilisé des gestionnaires de paquets et je n'ai pas le souvenir qu'ils m'aient donné une liste exhaustive de fichiers
Ou alors je n'ai pas fait attention vu que ça ne m'intéresse pas vraiment, en fait

Ça ne t'intéresse pas ?! Mais tu n'as pas honte ?!

Pen^2 (./4157) :
Ou alors je n'ai pas fait attention vu que ça ne m'intéresse pas vraiment, en fait

C'est peut-être plutôt ça, et t'inquiète pas le peux tout à fait le comprendre

(je viens d'ouvrir mon xubuntu pour regarder, c'est APT que j'avais utilisé, et j'ai la flemme d'installer un truc mais vraiment, je ne crois pas qu'il y avait la liste des fichiers — ou alors c'est une option... Ou alors il n'y avait que très peu de fichiers ?)

GoldenCrystal > lol, non, ça va, merci

Je dois être aveugle, mais je ne vois pas à quel endroit APT donne la liste et l'emplacement des fichiers écrits/modifiés sur le disque dur :
http://fr.wikipedia.org/wiki/Advanced_Packaging_Tool#apt-get

Pen^2 (./4160) :
ou alors c'est une option

Yep. "Show packages property in the main window". Ya les versions, la taille, les dépendances, les paquets qui dépendent d'icelui, etc..., et cette fameuse liste des fichiers.

Je parle de Synaptic :

Sinon, apt a des "à côté", apt-cache and co, c'est probable que l'un de ses séides sache faire ça.

Folco (./4156) :
ahah, je vois qu'on critique, on critique, mais on connais pas hein ?

Tiens depuis le temps que j'attendais que tu le dises pour te le retourner concernant Apple.
Mais je ne le ferai pas. C'est cool comme truc ça sinon. Enfin c'est mieux que rien, si on peut au moins voir ce qui est créé et où, trier rapidement (genre dans /slib, dan /usr/bin, etc.) et inclure aussi ce qui sera créé par les dépendances, alors on peut avoir déjà un aperçu de si une app fout la merde ou pas.

OK ça peut toujours être intéressant comme option (pour celui que ça intéresse, du moins ), mais, est-ce qu'il n'y a pas moyen d'avoir la liste sous OSX ? Sous Windows on l'a souvent aussi pendant l'installation (pour faire joli, et souvent dans un log également)

Pour OSX quand tu utilises un installeur (.pkg), il doit certainement moyen d'avoir la liste des fichiers, mais je ne m'y suis jamais intéressé…
Mais les installeurs OSX ne prévoient pas la désinstallation, donc de toutes façons, c'est de la merde.

Sinon pour une application normale, comme c'est juste un copier-coller (ou bien que ça passe par le Mac App Store… Ce qui revient presque au même ^^) il n'y a pas grand chose de secret

Un .pkg, ce n'est pas un installeur, c'est un paquet (assez similaire à un .deb). Tu peux l'installer via l'installeur graphique, ou en ligne de commande via pkgutil.
Ce dernier donne d'ailleurs accès à la liste des fichiers contenus (--files).

(Ouais enfin, un .deb, on peut le désinstaller, lui… )

OK merci.
GoldenCrystal >tiens, tu n'as pas honte non plus ?

GoldenCrystal (./4168) :
(Ouais enfin, un .deb, on peut le désinstaller, lui… )

pkgutil --unlink package-id ?