Windows Vista gratuit pour les étudiants - Page 8

./207 J'ai 2 Go, avec Java, Latex, OpenOffice,, serveurs WEB et SQL, KDE, des logiciels de dessin (Krita, Karbon), beaucoup d'environnements de développement (Ruby, C/C++, Python), de quoi jouer du multimédia, et quelques autres applications.
Ça ne me paraît pas énorme non plus

Sasume (./211) :
./207 J'ai 2 Go, avec Java, Latex, OpenOffice,, serveurs WEB et SQL, KDE, des logiciels de dessin (Krita, Karbon), beaucoup d'environnements de développement (Ruby, C/C++, Python), de quoi jouer du multimédia, et quelques autres applications.
Ça ne me paraît pas énorme non plus

comme quoi, une bonne gestion des dépendances n'apporte pas grand'chose

Surtout si c'est pour que la moitié des applications pètent dès que l'une d'elles met une librairie partagée à jour.

Bon, tout ceci ne changera de toutes façons pas la façon dont MacOS X (et j'espere Windows dans une prochaine version) fonctionnent; le délire de programmeur que sont les dépendances n'a à mon avis pas sa place dans un système qui se veut un minimum stable et utilisable par n'importe qui.

(bnuit )

Sasume (./203) :
Comme je l'ai déjà dit, Java, Latex, Office, sont des grosses applications, de plusieurs dizaines de Mo, si on utilise une dizaine de programmes utilisant l'un ou l'autre de ces logiciels, on se retrouve déjà avec près d'un Go de redondance...

Justement, en parlant de LaTeX, c'est un des trucs qui me font détester les dépendances... Genre pour compiler un fichier, j'ai besoin de make 3.81 qui n'existe absolument pas sur les debian stable, sachant que je ne suis pas admin de la machine, faut le recompiler à la main sans compter tous les autres petits programmes qui vont avec (genre transfig - à avoir en 3.2 alpha 4, sachant que le bousin ne marche pas sur OS X parce que le fork est fait à partir d'une autre version...), ... j'ai un peu du mal à voir l'intérêt pour l'utilisateur...

bnuit bob

Zephyr (./209) :
Windows ne vise pas à simplifier la vie des développeurs mais des utilisateurs, et un utilisateur veut que son application fonctionne; il se fiche totalement de savoir qu'il a gagné 10ko en partageant une librairie entre son traitement de texte et son logiciel de retouche photo, et surtout il ne veut pas que la mise à jour du traitement de texte risque de provoquer des changements (même positifs) dans une quelconque autre partie du système.

Euh ça doit dépendre des utilisateurs...
Perso je serais plutôt enchanté que mon moteur multimédia, suite à une mise à jour, allège à la fois la lecture des vidéos (par le lecteur vidéo), la lecture des CDs de musique (par le lecteur CD, qui est un programme très léger, dans le systray), l'encodage d'un CD de musique (par le graveur de CD, qui grave aussi des ISO d'ailleurs), etc.

Je ne comprends pas ce que tu veux "gérer" en fait, ni l'histoire de dépendances avec Java / LaTeX / Office. Ce sont des applications qui comme toutes les autres pourraient être de simples "boites noires", gérant les dépendances entre leurs différents modules (qui s'apparentent plus à des plug-ins) comme ça leur chante, mais surtout sans se reposer sur une éventuelle ressource partagée.

En fait, je trouve ça plus intéressant si le système d'exploitation lui-même évite aux développeurs des applications de (re)développer une solution.

tu crois vraiment que ça vaut le coup de rendre son système complètement bancal avec une gestion des dépendances juste pour économiser trois fois rien ?)

Euh, tu vas un peu vite là...
1. Gérer les dépendance ne rend pas le système bancal (au contraire)
2. Ce dont je parlais ne se limitait pas à une simple gestion de dépendances
3. OK pour la place gagnée qui n'est pas forcément significative (mais quand même pas inutile à mon goût).

Flanker (./210) :
Le .NET / java / Cocoa sont des trucs système et qui sont gérés par le système (pour les m)j, entre autres), mais c'est à peu près tout (tu peux les codecs audio/vidéos qui sont des plug-ins pour Quicktime)

Donc en fait le système applique une méthode sale pour tout de même bénéficier des avantages qui auraient été offert par un système de gestion de paquets.

mais quels logiciels ont Office comme dépendance ?

Imagine simplement qu'Office exporte des services permettant de traiter les fichiers Office, n'importe quel programme souhaitant supporter ces fichiers dépendra d'Office. Ou bien un programme permettant d'embarquer des composants d'Office (KDE exploite pas mal cette idée de composants embarqués).

Bah après, c'est surtout les développeurs qui ont des dll, tu as la même chose sous mac, mais tu ne le vois pas

Je voulais juste dire que de partager les librairies fait quand même partie des choix de Windows.

comme quoi, une bonne gestion des dépendances n'apporte pas grand'chose

Ben ton système est 50% plus lourd que le mien (je n'ai pas précisé que tout l'OS est également compris dans les 2 Go).
Enfin, de toute façon on n'a pas fait une comparaison très exhaustive... Donc ça ne vaut pas grand chose.

Zephyr (./213) :
Surtout si c'est pour que la moitié des applications pètent dès que l'une d'elles met une librairie partagée à jour.

Euh, ça c'est n'importe quoi
Si tu veux utiliser des versions instables des logiciels, c'est ton choix ! Tu peux n'utiliser que des versions stables aussi.

./214 > Effectivement, c'est un peu lourd comme situation... Mais je pense que c'est plutôt propre à linux de faire des tonnes de versions différentes d'un même programme.

Super, un bon vieux troll kernel vs nostub

Bon sinon j'ai peut-être rêvé mais je me demande si je n'avais pas lu écrire (équivalent d'entendu parler) d'une tentative d'uniformisation des installeurs pour vista, j'ai peut-être rêvé, faudra que je relise les dossiers sur la question...

Pour ma part, la seule fois où j'ai eu la malheureuse idée de tenter une installation linux les dépendances m'ont en effet pourri la vie malgré l'apt-get (ou à cause de lui ?)

J'ai tendance à penser (comme d'autres) que maintenant qu'on dispose de centaines de gigaoctets sur les plus petits disques durs en vente, utiliser des dépendances pour autre choses que les "briques système" (.NET, Java, DLLs système, drivers, etc) est pour le moins ridicule. Installer un logiciel libre (nottament) sur un poste qui n'a pas accès au net relève de l'impossible par exemple. Sans compter la désinstallation justement.

Bon je n'ai pas tout lu (trop long) mais en gros :

- Windows propose un service d'installation (MSI) meme si tout le monde ne l'utilise pas, il y a quand meme un service standard (et il est de plus en plus utilisé)

- Quand Flan liste 3Go d'application ça n'integre pas que les executables (j'imagine que tu as fait un "Information" sur le dossier application) ça integre aussi toutes les ressources (ou du moins une partie) des applications

- les Plugins dans les application sous Mac OS on 2 comportement
1 -> Le plugin est partagé entre tous les utilisateurs, il est donc mis dans le bundle de l'application
2 -> Le plugin est privé, et il est donc installé dans ~/Library/QQchose (ça dépend de l'application)
(Il existe un troisième choix qui est presque identique au comportement demandé au 1: le plugin est installé dans /Library/QQchose, mais c'est moins propre que le 1)

- On ne peut pas stoquer les préférences d'une application directement dans son bundle, du moins on ne peut pas le faire pour toutes les préférences simplement a cause du multi-utilisateur car chacun n'a pas forcement envie d'avoir les même préférences que les autres...

Sasume (./215) :
Euh ça doit dépendre des utilisateurs...Perso je serais plutôt enchanté que mon moteur multimédia, suite à une mise à jour, allège à la fois la lecture des vidéos (par le lecteur vidéo), la lecture des CDs de musique (par le lecteur CD, qui est un programme très léger, dans le systray), l'encodage d'un CD de musique (par le graveur de CD, qui grave aussi des ISO d'ailleurs), etc.

Tu es serieux quand tu dis ça ? Je veux dire, tu serais vraiment heureux d'apprendre que tu as gagné 20mo au total sur 50 applications en mettant je ne sais quoi à jour ? À mon avis non, ça ne dépend pas des utilisateurs, l'immense majorité n'en a rien à faire, simplement par le fait que 10 ou 15 des 5000 photos qu'ils ont sur leur disque prennent déjà bien plus que cette place gagnée, qui se retrouve donc être comparativement un gain insignifiant.

En fait, je trouve ça plus intéressant si le système d'exploitation lui-même évite aux développeurs des applications de (re)développer une solution.

On repart sur un point déjà abordé : pour moi Windows ne doit pas être orienté développeur si c'est au détriment des utilisateurs, Unix fait ça très bien (ok les derniers mots sont un troll pur, ceci dit il y a une part de vrai quand même, et Windows n'est clairement pas fait pour faciliter le travail des développeurs).

1. Gérer les dépendance ne rend pas le système bancal (au contraire)
2. Ce dont je parlais ne se limitait pas à une simple gestion de dépendances3. OK pour la place gagnée qui n'est pas forcément significative (mais quand même pas inutile à mon goût).

- perte d'autonomie de chaque soft + modification possible du comportement lors de chaque installation = instabilité
- tu ne parles que de ça depuis le début ?!
- cf points précedents, tu dois bien être l'un des seuls

Imagine simplement qu'Office exporte des services permettant de traiter les fichiers Office, n'importe quel programme souhaitant supporter ces fichiers dépendra d'Office. Ou bien un programme permettant d'embarquer des composants d'Office (KDE exploite pas mal cette idée de composants embarqués).

N'importe quel programme peut utiliser Office dès qu'il est installé, en utilisant les Automation Object de Microsoft. Et pas besoin de gestion de dépendances pour ça, il suffit de créer un AO sur "Excel.exe" par exemple, pour pouvoir le piloter en background et accéder à toutes ses fonctions.

Si tu veux utiliser des versions instables des logiciels, c'est ton choix ! Tu peux n'utiliser que des versions stables aussi.

Ça ne change rien : avec des dépendances, tu perds la garantie que l'installation d'un programme n'affectera pas le reste de ton système. Et c'est une perte *énorme* :/

J'avoue être plutôt d'accord avec Bob, mais le problème des codecs est assez important, surtout quand on fait du développement audio/vidéo, où les codecs évoluent rapidement mais pas les applis. Donc un peu de dynamisme ne fait pas de mal dans certaines situations (même si c'est vrai que j'avoue apprécier VLC parce que je sais qu'il intègre tout, mais on est dans un autre domaine d'activité).

Zephyr, je te trouve un peu de mauvaise foi pour le coup...
Ça tourne grave en troll j'ai l'impression de me répéter depuis le début.

Zephyr (./218) :

Sasume (./215) :
Euh ça doit dépendre des utilisateurs...Perso je serais plutôt enchanté que mon moteur multimédia, suite à une mise à jour, allège à la fois la lecture des vidéos (par le lecteur vidéo), la lecture des CDs de musique (par le lecteur CD, qui est un programme très léger, dans le systray), l'encodage d'un CD de musique (par le graveur de CD, qui grave aussi des ISO d'ailleurs), etc.

Tu es serieux quand tu dis ça ? Je veux dire, tu serais vraiment heureux d'apprendre que tu as gagné 20mo au total sur 50 applications en mettant je ne sais quoi à jour ? À mon avis non, ça ne dépend pas des utilisateurs, l'immense majorité n'en a rien à faire, simplement par le fait que 10 ou 15 des 5000 photos qu'ils ont sur leur disque prennent déjà bien plus que cette place gagnée, qui se retrouve donc être comparativement un gain insignifiant.

Je ne pensais pas forcément à un gain de place sur le disque, mais aussi un gain dans l'exécution.
Et je trouve ça vraiment curieux qu'on puisse être contre bénéficier des avantages d'une mise à jour d'une lib pour tous les programmes qui l'utilisent
Je ne vois vraiment pas quel avantage on a à avoir une occurence de lib (parfois différente) par application qui l'utilise.

En fait, je trouve ça plus intéressant si le système d'exploitation lui-même évite aux développeurs des applications de (re)développer une solution.

On repart sur un point déjà abordé : pour moi Windows ne doit pas être orienté développeur si c'est au détriment des utilisateurs, Unix fait ça très bien (ok les derniers mots sont un troll pur, ceci dit il y a une part de vrai quand même, et Windows n'est clairement pas fait pour faciliter le travail des développeurs).

OK.

1. Gérer les dépendance ne rend pas le système bancal (au contraire)
2. Ce dont je parlais ne se limitait pas à une simple gestion de dépendances3. OK pour la place gagnée qui n'est pas forcément significative (mais quand même pas inutile à mon goût).

- perte d'autonomie de chaque soft + modification possible du comportement lors de chaque installation = instabilité

Perte d'autonomie ? Ben non, chaque soft peut réinventer sa roue, mais je persiste à dire qu'on gagnera du temps à utiliser l'existant... Modification du comportement = instabilité : ok enfin, on est quand même dans l'optique que les mises à jour corrigent des bugs ou ajoutent des fonctionnalités plutôt que le contraire...

- tu ne parles que de ça depuis le début ?!

Euh non, c'est vous qui n'avez rebondi que là-dessus...

- cf points précedents, tu dois bien être l'un des seuls

Oui.

Imagine simplement qu'Office exporte des services permettant de traiter les fichiers Office, n'importe quel programme souhaitant supporter ces fichiers dépendra d'Office. Ou bien un programme permettant d'embarquer des composants d'Office (KDE exploite pas mal cette idée de composants embarqués).

N'importe quel programme peut utiliser Office dès qu'il est installé, en utilisant les Automation Object de Microsoft. Et pas besoin de gestion de dépendances pour ça, il suffit de créer un AO sur "Excel.exe" par exemple, pour pouvoir le piloter en background et accéder à toutes ses fonctions.

Oui, et ? Ça reviendrait au même avec un système de gestion de paquets, avec l'avantage que la technologie utilisée serait la même pour tous les programmes (donc on revient sur l'homogénéité de l'environnement)...

Ça ne change rien : avec des dépendances, tu perds la garantie que l'installation d'un programme n'affectera pas le reste de ton système. Et c'est une perte *énorme* :/

Je ne trouve pas.

Zephyr, je te trouve un peu de mauvaise foi pour le coup...Ça tourne grave en troll j'ai l'impression de me répéter depuis le début.

Le plus curieux c'est que j'ai exactement la même impression ^^
(et non je ne suis pas de mauvaise foi, je me demande comment il est encore possible aujourd'hui de considérer que les dépendances sont une bonne chose)

Je ne pensais pas forcément à un gain de place sur le disque, mais aussi un gain dans l'exécution.
Et je trouve ça vraiment curieux qu'on puisse être contre bénéficier des avantages d'une mise à jour d'une lib pour tous les programmes qui l'utilisent Je ne vois vraiment pas quel avantage on a à avoir une occurence de lib (parfois différente) par application qui l'utilise.

L'application fonctionne au jour J => j'ai la garantie qu'elle fonctionnera aux jours J+X même si j'installe plein d'autres programmes à coté (et non, ce n'est pas garanti avec les dépendances; l'experience prouve qu'il y a toujours des problèmes d'incompatibilité)

Perte d'autonomie ? Ben non, chaque soft peut réinventer sa roue, mais je persiste à dire qu'on gagnera du temps à utiliser l'existant...

Mais qui a parlé de ne pas l'utiliser ? Personne. Il est simplement question d'utiliser *sa* roue plutôt que celle du voisin, en la copiant (donc hors de question de réinventer quoi que ce soit), même si au moment de la copie les deux sont parfaitement identiques. Pourquoi ? Parcequ'une roue ça coute pas cher, et qu'au moins si le voisin décide de mettre la sienne à jour, je n'ai pas à le faire et je suis sûr que celle que j'avais avant fonctionne très bien pour ce que j'avais à faire avec.

Modification du comportement = instabilité : ok enfin, on est quand même dans l'optique que les mises à jour corrigent des bugs ou ajoutent des fonctionnalités plutôt que le contraire...

Oui heureusement, mais ne me dis pas que tu n'as jamais été confronté à ce genre de problèmes...

Euh non, c'est vous qui n'avez rebondi que là-dessus...

Bah alors quoi d'autre ? J'ai beau relire je ne vois pas de quoi d'autre tu as parlé ?

Oui, et ? Ça reviendrait au même avec un système de gestion de paquets, avec l'avantage que la technologie utilisée serait la même pour tous les programmes (donc on revient sur l'homogénéité de l'environnement)...

Non, puisqu'avec ton système, il y a des dépendances (et donc tous les problèmes qui y sont liés, cf tous les posts précedents).

Je ne trouve pas.

Tu ne trouves pas que risquer d'avoir une application qui ne fonctionne plus correctement à chaque fois que tu en installes une autre est une perte de fiabilité énorme ? Je n'ai plus rien à ajouter alors, mais ne viens pas expliquer que c'est moi qui suis de mauvaise foi...

Ximoon (./216) :
Super, un bon vieux troll kernel vs nostub

T1 c'est vraiment ça en plus

clairement, si un problème (éventuellement de sécurité) dans une lib est découvert, il vaut mieux qu'il ne soit pas corrigé pour tous les programmes utilisant la lib, pas vrai ?

Euh je suis d'accord avec bob aussi...

Zephyr (./213) :Surtout si c'est pour que la moitié des applications pètent dès que l'une d'elles met une librairie partagée à jour

Je vais prendre un exemple au hasard choisi par moi-même... GTK+, avec The Gimp et Ti-Emu. Les deux nécessitent cette lib, mais chacun une version différente. Il sera assez compliqué de faire coexister une distrib de The Gimp avec Ti-Emu, car si l'un marche, l'autre se plantera lamentablement...

mince, je dois être un surhomme, je viens d'installer les 2 pour l'occasion et les lancer et ça marche

Hum cela dit, je suis d'accord qu'en théorie, travailler avec des librairies partagées, c'est le mieux. Mais dans la mesure où les fournisseurs ne sont pas capable de proposer une solution efficace (sous Windows, je n'ose même plus regarder l'état de system32 et de la base de registre, c'est infernal, même pour des applications censées être vraiment propres (anti-virus...) ; sous Linux, c'est la merde entre les versions 32 bits ou 64 bits, packagée pour telle ou telle distrib, les librairies que tu ne peux pas mettre à jour sans désinstaller totalement ton serveur X et tout ce qui en dépend (si, si, j'ai eu le problème pour mettre à jour OpenSSH x_x, ou alors il faut forcer l'opération, mais on m'a toujours appris que c'était mal de forcer, que ça voulait dire que c'était pas fait pour). Donc effectivement, le bundle applicatif reste encore la meilleure solution.

Zephyr > Ok, ok. Moi je trouve que les avantages d'un système de gestion de paquets contrebalancent ses désavantages. Effectivement, si une maj d'une lib ajoute un bug et plante tous les programmes l'utilisant, c'est foireux... Mais il y a d'autres avantages (j'ai cité les principaux au post ./194 et tu y as répondu).

À mon avis la réponse c'est surtout que les OS plutôt orientés utilisateurs (OSX, Windows) semblent vouloir s'affranchir de plus en plus du principe de dépendance, tandis que le monde d'Unix l'améliore pour ne garder que ses avantages. Dans un cas comme dans l'autre, il me semble que cela prouve que la solution actuelle n'est pas parfaite, et cette différence d'orientation ne donne qu'une raison de plus de préferer tel ou tel système. Dans tous les cas, il est probablement trop tôt pour déterminer quelle est finalement la "meilleure" solution (à supposer qu'il y en ait une).

Nil (./219) :
J'avoue être plutôt d'accord avec Bob, mais le problème des codecs est assez important, surtout quand on fait du développement audio/vidéo, où les codecs évoluent rapidement mais pas les applis. Donc un peu de dynamisme ne fait pas de mal dans certaines situations (même si c'est vrai que j'avoue apprécier VLC parce que je sais qu'il intègre tout, mais on est dans un autre domaine d'activité).

En meme temsp les codecs sont souvent installé en un endroit qui les rend pratiquement utilisable par toutes les applis qui savent les utiliser..

Ensuite il y a bien une "notion" de lib partagé que ça soit sous windows ou sur mac os X (les DLL "system" pour l'un, les framework pour l'autre) qui peuvent etre interne a l'appli (dans le dossier pour windows, et dans le bundle pour max os X) ou partagé

Sasume (./220) :

Zephyr (./218) :

Sasume (./215) :
Euh ça doit dépendre des utilisateurs...Perso je serais plutôt enchanté que mon moteur multimédia, suite à une mise à jour, allège à la fois la lecture des vidéos (par le lecteur vidéo), la lecture des CDs de musique (par le lecteur CD, qui est un programme très léger, dans le systray), l'encodage d'un CD de musique (par le graveur de CD, qui grave aussi des ISO d'ailleurs), etc.

Tu es serieux quand tu dis ça ? Je veux dire, tu serais vraiment heureux d'apprendre que tu as gagné 20mo au total sur 50 applications en mettant je ne sais quoi à jour ? À mon avis non, ça ne dépend pas des utilisateurs, l'immense majorité n'en a rien à faire, simplement par le fait que 10 ou 15 des 5000 photos qu'ils ont sur leur disque prennent déjà bien plus que cette place gagnée, qui se retrouve donc être comparativement un gain insignifiant.

Je ne pensais pas forcément à un gain de place sur le disque, mais aussi un gain dans l'exécution.
Et je trouve ça vraiment curieux qu'on puisse être contre bénéficier des avantages d'une mise à jour d'une lib pour tous les programmes qui l'utilisent Je ne vois vraiment pas quel avantage on a à avoir une occurence de lib (parfois différente) par application qui l'utilise.

Quand une appli utilise un bug (ou un comportement indéfini) de façon précise et qu'elle se met à déconner si elle utilise le bug corrigé, ou si l'API de la lib change ... et que naturellement une autre appli utilise la version récente de la ilb, là tu as un avantage à avoir une version de la lib par application

Perte d'autonomie ? Ben non, chaque soft peut réinventer sa roue, mais je persiste à dire qu'on gagnera du temps à utiliser l'existant... Modification du comportement = instabilité : ok enfin, on est quand même dans l'optique que les mises à jour corrigent des bugs ou ajoutent des fonctionnalités plutôt que le contraire...

Tu peux très bien réutiliser l'existant, c'est juste que tu en auras plusieurs copies...

Ça ne change rien : avec des dépendances, tu perds la garantie que l'installation d'un programme n'affectera pas le reste de ton système. Et c'est une perte *énorme* :/

Je ne trouve pas.

Compromettre ton système entier rien qu'en installant une visionneuse photo (vécu y a pas si longtemps), tu ne trouves pas ça une perte énorme ?

Godzil (./229) :

Nil (./219) :
J'avoue être plutôt d'accord avec Bob, mais le problème des codecs est assez important, surtout quand on fait du développement audio/vidéo, où les codecs évoluent rapidement mais pas les applis. Donc un peu de dynamisme ne fait pas de mal dans certaines situations (même si c'est vrai que j'avoue apprécier VLC parce que je sais qu'il intègre tout, mais on est dans un autre domaine d'activité).

En meme temsp les codecs sont souvent installé en un endroit qui les rend pratiquement utilisable par toutes les applis qui savent les utiliser..

Je suis d'accord, il y a un certain nombres de trucs qui doivent être gérés par le système, mais à mon goût, la vidéo et le son font partie du « framework » de base, au même titre que l'affichage des fenêtres ou les boîtes de dialogue. Du coup, on fait un plug-in pour le système, pas pour une appli donnée.

Accessoirement, pour l'installation de logiciels sous Vista, je crois me souvenir que ce n'est pas encore obligatoire d'utiliser un installeur « propre » (essentiellement pour des raisons de compatibilité), mais par contre, pour la prochaine version de Windows (NT 7.0) ça sera le cas.

(oh oui, !invite kevin )

bon, vite fait :
- vous vous focalisez sur le problème de la place, alors que c'est clairement pas le facteur le plus important : pour linux, l'intérêt c'est surtout de ne pas avoir à définir de frontières claires système/pas système et de permettre d'avoir plein de couches successives sans que ça soit un cauchemar pour l'utilisateur
- pour ce qui est de la stabilité, c'est complètement indépendant du fait d'avoir une gestion des dépendances : c'est pas parce que java n'est pas installé automatiquement qu'une mise à jour de java sous windows ne va pas non plus foutre en l'air tous les programmes qui l'utilisent ; la raison pour laquelle ça n'arrive pas, c'est simplement que les mises à jour des libs (java, .net, codecs...) sont suffisamment rares/stables pour ne rien casser, alors que sous linux la tentation est forte d'utiliser une version instable (il suffit qu'un prog ait besoin d'une version instable pour être obligé de prendre des risques)

Pollux (./232) :
(oh oui, !invite kevin )

bon, vite fait :
- vous vous focalisez sur le problème de la place, alors que c'est clairement pas le facteur le plus important : pour linux, l'intérêt c'est surtout de ne pas avoir à définir de frontières claires système/pas système et de permettre d'avoir plein de couches successives sans que ça soit un cauchemar pour l'utilisateur

ah non, on ne parle pas que du problème de place (en tout cas pas moi ^^ )

- pour ce qui est de la stabilité, c'est complètement indépendant du fait d'avoir une gestion des dépendances : c'est pas parce que java n'est pas installé automatiquement qu'une mise à jour de java sous windows ne va pas non plus foutre en l'air tous les programmes qui l'utilisent ; la raison pour laquelle ça n'arrive pas, c'est simplement que les mises à jour des libs (java, .net, codecs...) sont suffisamment rares/stables pour ne rien casser, alors que sous linux la tentation est forte d'utiliser une version instable (il suffit qu'un prog ait besoin d'une version instable pour être obligé de prendre des risques)

Nan, là je ne suis pas complètement d'accord ce n'est pas parce que ce n'est pas installé automatiquement qu'il n'y a pas de dépendance Dès qu'il y a des dépendances, il y a un risque de casser toutes les applis qui en dépendent, évidemment (donc la stabilité va dépendre des dépendances). D'où l'intérêt de séparer le système (avec des mises à jour rares/stables, sans 10 000 versions différentes, ... ) et les applis qui ne doivent pas pouvoir modifier le système.

Flanker (./233) :

Pollux (./232) :
(oh oui, !invite kevin )

bon, vite fait :
- vous vous focalisez sur le problème de la place, alors que c'est clairement pas le facteur le plus important : pour linux, l'intérêt c'est surtout de ne pas avoir à définir de frontières claires système/pas système et de permettre d'avoir plein de couches successives sans que ça soit un cauchemar pour l'utilisateur

ah non, on ne parle pas que du problème de place (en tout cas pas moi ^^ )

je parlais pas de toi en particulier, je disais juste que j'avais juste lu en gros "les dépendances c'est nul parce que ça sert juste à économiser 3% du disque dur, ils sont vraiment trop cons les gens de linux" (bon, j'extrapole un peu mais l'idée est là ) alors que c'est pas vraiment la raison principale...

- pour ce qui est de la stabilité, c'est complètement indépendant du fait d'avoir une gestion des dépendances : c'est pas parce que java n'est pas installé automatiquement qu'une mise à jour de java sous windows ne va pas non plus foutre en l'air tous les programmes qui l'utilisent ; la raison pour laquelle ça n'arrive pas, c'est simplement que les mises à jour des libs (java, .net, codecs...) sont suffisamment rares/stables pour ne rien casser, alors que sous linux la tentation est forte d'utiliser une version instable (il suffit qu'un prog ait besoin d'une version instable pour être obligé de prendre des risques)

Nan, là je ne suis pas complètement d'accord ce n'est pas parce que ce n'est pas installé automatiquement qu'il n'y a pas de dépendance Dès qu'il y a des dépendances, il y a un risque de casser toutes les applis qui en dépendent, évidemment (donc la stabilité va dépendre des dépendances). D'où l'intérêt de séparer le système (avec des mises à jour rares/stables, sans 10 000 versions différentes, ... ) et les applis qui ne doivent pas pouvoir modifier le système.

ben oui, je suis tout à fait d'accord () : java/.net/etc font partie du système et sont stables, alors que sous linux c'est bien plus délicat...

Pollux (./232) :
bon, vite fait :[ ... ]

(j'aime bien cette façon de présenter les choses : "bon, je vous apporte la bonne parole mais j'ai pas trop de temps à vous consacrer alors concentrez-vous ")

Flanker (./231) :
Accessoirement, pour l'installation de logiciels sous Vista, je crois me souvenir que ce n'est pas encore obligatoire d'utiliser un installeur « propre » (essentiellement pour des raisons de compatibilité), mais par contre, pour la prochaine version de Windows (NT 7.0) ça sera le cas.

(si blackcomb sort un jour..)

Sasume:

./231: Le jour où Windows ne supporte plus Quake 3, il est mort aux yeux de tous mes collègues

PpHd (./237) :
Sasume:

quels points en particulier ?

./231: Le jour où Windows ne supporte plus Quake 3, il est mort aux yeux de tous mes collègues

Suffit de faire un installeur propre... Y a bien eu une conversion par des amateurs d'une architecture PPC à une architecture Intel, et je pense que c'est plus compliqué...

Ben le '.', le ':' mais aussi le ';' et le '!'. Je pense que c'est tous les points qu'il a utilisé. Ah ! J'allais oublié le '?' !

Zephyr (./235) :

Pollux (./232) :
bon, vite fait :[ ... ]

(j'aime bien cette façon de présenter les choses : "bon, je vous apporte la bonne parole mais j'ai pas trop de temps à vous consacrer alors concentrez-vous ")

je voulais juste dire que j'avais pas trop le temps de bien rédiger ou de tout mettre donc que ça serait un peu en vrac (#tard# toussa), mais apparemment même avec un avertissement pour dire que j'avais pas spécialement fait attention à la forme ça suffit pas pour t'empêcher de monter sur tes grands chevaux :/

PpHd (./237) :
./231: Le jour où Windows ne supporte plus Quake 3, il est mort aux yeux de tous mes collègues

pourquoi est-ce qu'il ne faudrait pas le supporter ? une app crade qui s'installe sans préciser à windows ce qu'elle installe, il suffit de la faire tourner dans une sandbox isolée -- inversement, pour une app qui a vraiment besoin d'installer des fichiers systèmes c'est la moindre des choses d'utiliser MSI
bon alors après je ne sais pas si NT7 fera comme ça, mais ça ne me surprendait pas du tout que ça soit le cas ^^