Chocolatey : un package manager pour Windows - Page 2

Il y a très peu d'applications qui fonctionnent ainsi. Pour ne pas dire aucune. En général, ce sont plutôt les drivers, ou les logiciels du constructeur de la machine (Asus, Sony, et ali aiment bien avoir, en plus de leurs logiciels pourris, un vérificateur de mise à jour au démarrage pour celles-ci).
LibreOffice/OpenOffice a son "démarrage rapide" qui est chargé en mémoire, mais je ne suis même pas certain qu'il gère les vérifications de mises à jour (et il est opt-in depuis plusieurs années).
Même les suites Adobe, qui aiment installer plein de trucs résidents au démarrage, ne gèrent pas les mises à jour ainsi...

(Trollolilol ?)

Oui perso je n'ai aucun app qui télécharge les maj automatiquement, sauf l'antivirus mais ça c'est normal.

Pareil. Je sais pas d'où tu sors ça, Kevin ^^

Perso je confirme Kevin, même s'il exagère un peu. Dans une install classique de Windows on a plein de services qui attendent l'update. Autant il y a des défaut au système des packages classique Linux, la simplicité d'update est vraiment un atout.

Eh bien à part Flash (que je pourrais désactiver), je n'ai rien qui ne recherche de mise à jour au boot. Ca doit dépendre des configs, comme d'habitude.

Parmi les plus connus il y a Chrome, Mozilla, Flash, Java, ... Celui de chrome étant particulièrement vicieux car pas désactivable sans manipulation complexe.
Après la recherche ne se fait pas forcément au moment du boot, mais ça reste idiot de multiplier les service pour faire à peu près la même chose.

j'ai plutôt la même impression qu'Uther (même si je n'ai plus de java sur ma machine).
Cela dit, ce n'est pas la centralisation des dépôts qui est importante mais le système de paquet.
On pourrait très bien imaginer que chaque logiciel est empaqueté de la même façon et contient l'adresse d'un miroir.
Il est alors simple de faire un programme (idéalement fourni par l'OS) de parcourir tous les paquets installés, d'interroger les différents miroirs et d'aller récupérer les différentes mises à jour.
Malheureusement, ce n'est pas la voie qui a été suivie (ce n'était pas viable aux débuts de Windows, et ils n'ont pas profité des dix dernières années pour la pousser)

Je n'ai ni Chrome, ni Java, ça doit expliquer des choses
Par contre, Firefox ne fais des majs que quand il est lancé, d'après ce que je vois.
Bon ok, il est lancé 99% du temps, mais quand même, il ne me propose jamais de maj au moment du boot.

Folco (./39) :
Par contre, Firefox ne fais des majs que quand il est lancé, d'après ce que je vois.Bon ok, il est lancé 99% du temps, mais quand même, il ne me propose jamais de maj au moment du boot.

Ça dépend des options de mise a jour que tu as choisi, mais avec les paramètres par défaut, sous Windows, Il y a un service qui se nome Mozilla maintenance qui fait les mise a jour en tache de fond silencieusement quand Firefox est éteint. Après si ton Firefox est allumé depuis trop longtemps, il va te prévenir car il faut le redémarrer pour faire l'installation.

Chrome mozilla flash java, ça fait 4 programmes, on est loin du système bloqué par des maj au démarrage.

Il me semble que le service Mozilla n'est plus installé par défaut (mais qu'il l'était lors des vieilles versions).
Cela dit, j'avais oublié Java (qui est méga chiant, je suis 100% d'accord >.<), mais c'est parce que je ne l'ai plus que sur ma machine Linux.

Je ne sais pas si Java est encore beaucoup installé sur les nouveaux Windows

Je ne pense pas, mais il y a encore pas mal de projets OSS qui sont basés dessus et qui n'ont pas vraiment d'alternative viable non-java (voire même commerciale). Je pense à yEd, FreeMind (ou des outils plus spécifiques comme LDAP Browser/Editor ou SQuirelL).
Mais je suis d'accord aussi que c'est moins le fait qu'il y ait une vérification des mises à jour qui pose problème que la façon dont c'est géré (chacun dans son coin, de façon non centralisée...).
En fait, on pourrait très bien avoir une alternative au système de paquets avec repo centralisé comme sous Linux, et qui serait un gestionnaire centralisé (sous forme de service+appli), proposé par Microsoft dans Windows, où chaque application pourrait s'enregistrer au moment de l'installation, avec un serveur sécurisé (pas de Microsoft, mais géré par les développeurs de l'application installée) à l'autre bout et une API d'échanges d'informations.

ça ressemble au store d'application depuis W8 ou je me trompe ?

Non, le Store est 100% géré par Microsoft (et ne concerne que les applications ModernUI).
Chocolatey utilise un repo indépendant pour, justement, toutes les applications.
La solution que je propose serait pour toutes les applications, et localement.

Non le store ne concerne pas que les application ModernUI, mais les "Universal Windows Platform" qui peux etre une app "Win32/64" mis en bouteille dans un appx grace au "desktop bridge" : https://blogs.windows.com/buildingapps/2016/05/17/bringing-your-existing-desktop-apps-to-uwp/#rlqApFggFq1Cl5z5.97

Il n’empêche que tu reste dépendant de Microsoft.
Pour moi c'est un non direct.

En quoi tu es plus dependent que en faisant des .exe "classiques" ?

Tu n'es pas oblige de distribuer des app UWP via le Windows Store si c'est ce a quoi tu penses.

Ce que veut dire Uther (et que j'approuve), c'est qu'en passant par le Store de MS, tu as tous les inconvénients d'un tel système :
- Microsoft sait tout ce que tu installes (tu vas me dire qu'il le sait peut-être déjà, mais là c'est clair, net et officiel)
- On connaît les soucis des applis retirées des Stores avec les impacts que ça a derrière
- Ca oblige les développeurs à suivre des règles (voire à devoir payer) avec lesquelles on n'est pas forcément d'accord et ça asservit les éditeurs tiers au bon vouloir de MS quant à la visibilité des applications
- En cas de rupture du service (problème réseau, d'infra, ou décision politique/économique - on l'a déjà vu avec le Cloud de certains prestataires), on est bloqué
- Pas de possibilité d'avoir différents canaux de distribution (si je ne m'abuse, on ne peut avoir sur le Store MS des applis en beta ou nightly).
- Le Store MS est aujourd'hui extrêmement fragile car il n'est pas une application au sens classique (c'est la seule chose qui a pété dans mon install Windows 10 suite à une mise à jour, nous étions plusieurs milliers dans ce cas dans le monde, toutes les applications installées depuis le Store étaient ainsi cassées, les différentes réparations de Windows étaient en échec systématique [y compris la réinstallation sans perte]... il a fallu attendre l'anniversary update pour que ça se débloque, soit plus de 6 mois dans mon cas... heureusement que la seule appli liée au Strore que j'utilisais était le lecteur PDF !). Tous les mois, après la délivrance du patch mensuel, un nouveau ticket était créé par MS sur leur forum, tous les mois le gars qui le suivait priait pour que ça ait résolu le problème pour tout le monde. Tous les mois, c'était un échec (pourtant, il en a eu, des dumps système )
- etc.

Alors je me répète, mais UWP ne te force PAS a utiliser le Windows Store. Et rien ne t'empeche de distribuer ton app via plusieurs moyen.

Et je ne faisais que corriger le fait que le Windows Store n'est pas que pour les app en "ModernUI", le reste, je doute que "rupture de service" s'applique un jour chez Apple ou Microsoft pour leur App Store respectifs, et le bug que tu as eu, tout en etant assez surprenant qu'il n'y ai aucun moyen de le resoudre est, malheureusement, plus l'exception que la regle de ce cote (meme si ce que fait Microsoft et est reste fragile et peux planter/foirer assez facilement..)

Godzil (./51) :
Alors je me répète, mais UWP ne te force PAS a utiliser le Windows Store. Et rien ne t'empeche de distribuer ton app via plusieurs moyen.

Oui, oui, mais le problème soulevé n'est pas celui-ci (d'ailleurs, ma note concernant la limitation à ModernUI était entre parenthèse).
La question est d'utiliser un outil permettant de gérer les mises à jour de façon souple, sans intermédiaire technique qui va inévitablement venir avec ses limitations. loclamor pensais que Windows Store répondait à ce problème, Uther et moi ne sommes pas d'accord (la limitation à UWP n'est qu'un élément parmi d'autres).

Sinon

Godzil (./51) :
je doute que "rupture de service" s'applique un jour chez Apple ou Microsoft pour leur App Store respectifs

Oh, personne ne pensait que Nokia fermerait son Cloud, que Google fermerait autant de services (tiens, l'API Hangout va être bloquée du jour au lendemain), Apple éjecte régulièrement des applications de son store (parfois pour de simples raisons idéologiques), et Google en refuse pour des raisons identiques.
Je ne veux pas qu'un tiers sache que j'ai installer FouetteMoiEnCostumeUrside 3.2, ni que, si je l'ai installé, il puisse choisir de le retirer des applications autorisées. Par contre, j'aime bien que mon appli soit à jour, surtout parce qu'on peut utiliser des orties fraîches dans la version 3.2.1, et qu'une faille de sécurité permettant à n'importe qui de m'espionner sur ma webcam a été corrigée par la même occasion, du coup ce serait cool que je puisse voir en un endroit centralisé sur mon système toutes les mises à jour afin de les gérer simplement.

Il faudrait donc un système comme sous GNU/Linux, où tu as un dépôt central, mais où tu peux aussi rajouter des dépôts tiers qui fonctionnent exactement de la même manière et seront pris en compte par le même système de mises à jour.

Non, parce que les dépôts façon GNU/Linux ne permettent pas à une application installée d'ajouter sa source de façon simple.

C'est parce que tu penses la chose à l'envers, ce n'est pas à l'application de rajouter le dépôt (même si c'est possible, Google Earth fait ça, par exemple), mais tu rajoutes d'abord le dépôt qui te propose ensuite l'application.

Sauf que rajouter un dépôt c'est plus complexe que de lancer une installation sur Windows ou Mac.

Tu installes un paquetage machinchose-release qui configure le dépôt (et se met à jour lui-même à travers le dépôt) et c'est bon. C'est même plus simple que les procédures d'installation qui te demandent 36000 choses.

(Mais dans le cas idéal, le logiciel est dans le dépôt officiel, ce qui t'épargne tout le cirque de trouver le site web du logiciel que tu as sous Windows et Mac. )

C'est vrai que pour le coup, c'est pas idiot comme manière de procéder, même si ça serait plus propre d'avoir un mécanisme fait pour cela plutôt que de détourner le système de package.

Mais je ne connais aucun logiciel qui propose de s'installer ainsi.

Oui, et c'est bien dommage
Le concept de dépôt principal est intéressant, mais a des inconvénients :
- être tributaire des mainteneurs du dépôt (qui peuvent faire des choix idéologiques ou politiques et qui sont un intermédiaires de plus entre de développeur et l'utilisateur
- une fois qu'un dépôt n'est plus maintenu (distribution morte, version dépassée), on se retrouve avec un système statique et non évolutif même pour installer une bête application indépendante (sauf à passer par un binaire d'installation ou un tarball) [autant dire : vive la rolling release !]
- être un élément de centralisation (ce qui est toujours un souci, et qui est contraire à la logique d'Internet... même s'il y a la notion de miroirs qui affaiblit le risque, il n'empêche qu'un miroir n'est qu'un miroir, donc peut mener à des soucis)
- il y a autant de dépôts que de distributions (ou presque), et plusieurs gestionnaires de paquets/dépendances rendant difficile l'interopérabilité

Ca a aussi des avantages :
- paquets normalement revus, vérifiés, adaptés à un environnement donné
- adapté à un contexte d'OS modulaire, avec la gestion des dépendances et des versions (ce qui est plus difficile si chaque éditeur de logiciel installe son propre dépôt, sauf à avoir des mécanismes pouvant permettre de gérer aussi des dépôts tiers)

Ha oui on installe un packate du depot X pour installer un depot Y...

Oh wait?

Si Y existe officiellemetn pour X, pourquoi il y en a deux?

Je n'avais encore jamais entendu un tel truc aussi absurde :/