Microsoft ontwikkelt opensource package manager voor Windows

Microsoft heeft een bèta van een eigen package manager uitgebracht. Met deze functie, die het bedrijf 'winget' noemt, kunnen gebruikers applicaties installeren via de terminal. De werking is grotendeels gelijk aan die van Linux-package managers.

Microsoft meldt dat de winget-functie momenteel beschikbaar is als bètaversie en dat de definitieve versie nog substantieel kan veranderen. Versie 1.0 staat in de planning voor 2021. Om de feature te gebruiken, moeten gebruikers momenteel eerst een Windows 10 Insider-build installeren, of handmatig toegang aanvragen voor de bètaversie. Omdat de package manager opensource is, kunnen gebruikers de functie ook zelf compilen met Visual Studio 2019 en C++.

Na installatie kunnen gebruikers de functie starten door 'winget' te typen in de command-prompt. Om naar programma's in de repository te zoeken, kunnen gebruikers bijvoorbeeld 'winget search \<appname>' typen. Als het programma naar keuze beschikbaar is, kan het geïnstalleerd worden met het install-commando. De functie kan verder gebruikt worden om een sha256-checksum van applicaties te genereren. Ook kunnen mensen applicaties insturen voor toevoeging aan de repository van Microsoft.

Versie 1.0 van de winget-feature staat op de roadmap voor mei 2021. Wel stelt Microsoft dat het bedrijf 'substantiële feedback' van de community verwacht, waardoor de planning mogelijk verandert. Er worden enkele grote features toegevoegd aan versie 1.0, waaronder de mogelijkheid om apps via de command-prompt te updaten en te deïnstalleren.

De winget-feature in gebruik. Afbeelding via Microsoft

Reacties (133)

Het is simpelweg een script die bestaande executables download en deze stilletjes installeerd

Totale flop. Enkele (Linux) ontwikkelaars over op Reddit zijn er vannacht al doorheen gegaan en hebben gezien hoe dit totaal geen beschikte package manager is:
https://www.reddit.com/r/..._windows_package_manager/

Hier bullet points van alle miskleunen:
- Geen enkele versioning
- Geen enkele rollback mogelijkheden
- Geen sandboxing
- Geen dependency managmenent
- Geen user/system space scheiding
- Geen cryptografische beveiliging of templating
- Geen auto update mechanismen
- Geen un-install mechanismen
- Geen config manamement

Dit is een itern-project welke ongeveer twintig jaar achter de feiten aan loopt. Hier een issue om aan MS te vragen om het te hernoemen:
https://github.com/microsoft/winget-cli/issues/223

Edit.

Inhakende op het: "Maar het is nog niet af!"-commentaar. Dit gaat nooit lekker werken tenzij de complete basis ververangen. Software packaging systemen zijn super complex en de infrastructuur omdat allemaal goed te organiseren schut je niet zomaar uit de mouw.

Hoe het nu opgezet is kun net zo goed Ninite gebruiken.

[Reactie gewijzigd door Eonfge op 20 mei 2020 10:50]

Ik vind dat je commentaar de plank redelijk misslaat. Het doel van deze tool is volgens hun GitHub pagina dit:

The Windows Package Manager is a tool designed to help you quickly and easily discover and install those tools that make your PC environment special.

Het is dus voor eindgebruikers en niet voor servers e.d. Nu wil het geval dat Windows heel anders werkt dan Linux, en dat ook het Windows software ecosysteem heel anders in elkaar zit. Windows software wordt doorgaans verspreid als installer, danwel via de Microsoft Store en dat is gewoon een facade voor vergelijkbare installers.

Dit in tegenstelling tot Linux, waar de meeste software als packages wordt verspreid met een hele rits dependencies. Een package voor, zeg, nodejs, zal dus alleen de code bevatten van NodeJS zelf, en alle dependencies (openssl, etc etc whatever) worden geacht al aanwezig te zijn op het systeem. Als dat niet zo is, lost de package manager dit voor je op. Of niet natuurlijk, en dan krijg je een bende met conflicterende dependencies. Eén van de voornaamste doelen van linux-distributies is zorgen dat je die bende niet krijgt, en dat kost een hoop vrijwilligerswerk.

Op Windows heeft Chocolatey geprobeerd dat model na te bootsen, met als gevolg precies zo'n bende met dependencies.

Daarom is later door een andere programmeur Scoop gelanceerd, en Scoop is ronduit fantastisch. It just works: "scoop install nodejs php git" en boem je bent klaar. Het geheim van Scoop? Precies datgene waar jij zo lacherig om doet.

In de meeste Windows software zitten bijna altijd alle dependencies in dezelfde directory als de applicatie. De installer kopieert die gewoon mee. Chocolatey probeerde dat uit elkaar te trekken en een Linux-model na te bootsen, met een enorme wirwar als gevolg. Maar Scoop doet precies dat: Scoop downloadt een installer, unzipt hem achter de schermen, en stelt je PATH zo in dat je vanaf de command line bij te tool kunt. Auto update? Nop. Sandboxing? Laat me niet lachen. Maar het werkt als een malle.

En dat is zo omdat het aansluit bij de manier waarom Windows software nu al gebundeld en verspreid wordt.

Ik heb recent door hardwareproblemen mijn computer een aantal keer opnieuw moeten installeren, en door Scoop was dit echt een fluitje van een cent (Ninite is ook vet trouwens, daar niet van - en om ongeveer dezelfde redenen).

Dus als Winget het Ninite/Scoop model overneemt, is dat m.i. veel beter dan het Linux model. Het past bij hoe Windows werkt, het past bij hoe het Windows ecosysteem werkt. Dat allemaal Linux-fanaten daar dan lacherig over doen vind meer zeggen over hen dan over het team achter Winget.

Overigens heb ook ik nog wel wat te mopperen:

1. Waarom maakt Microsoft hier weer wat nieuws, ipv bijv aan te sluiten bij Scoop? Ze hebben eerder al NodeJS geschikt(er) voor Windows gemaakt met een enorme inspanning, dus ze hebben laten zien dat ze best bestaande OSS kunnen adopteren. Vooralsnog voelt dit bij mij als nodeloze Not Invented Here.
2. Waarom noemen ze het in hemelsnaam een "package manager" als het een "software installer" is? Als ze die term niet hadden gebruikt hadden ze de helft van de hoon van mensen die Linux gewend zijn kunnen overslaan.

Sidenote: Ik zou auto-update voor mijn command line tools echt verschrikkelijk vinden. Als mijn hele team op Java 9 zit en mijn "package manager" besluit dat dat écht niet meer bij de tijd is, loopt alles in de soep. No thanks, ik doe wel `scoop update java`.

[Reactie gewijzigd door skrebbel op 20 mei 2020 12:07]

Ik kan in ieder geval antwoord geven op je eerste mopper.

"Why not contribute to another open source package manager?
We looked at several other package managers. There were several reasons leading us to create a new solution. One critical concern we had was how to build a repository of trusted applications. We are automatically checking each manifest. We leverage SmartScreen, static analysis, SHA256 hash validation and a few other processes to reduce the likelihood of malicious software making its way into the repository and onto your machine. Another key challenge was all the changes required to be able to deliver the client program as a native Windows application." - https://devblogs.microsof...-package-manager-preview/

Ja ik had het ook gelezen, maar ik vind het een non-antwoord. Er is m.i. niets aan de architectuur of visie van Scoop dat het lastig maakt die zaken aan Scoop te contributen.

En aan om het even welke andere package manager.

Het moge zo zijn dat de manier waarop windows programma's gebundeld zijn "just works", vanuit een beveiligingsoogpunt is het een ramp.

Vooropgesteld: ook op een linux systeem kun je software installeren zoals dat op Windows de manier is. Een shellscript dat zichzelf en een aantal libraries uitpakt, even de bin directory aan het path toevoegen of symlinks naar de binaries maken in /usr/local/bin en je bent klaar. Matlab gebruikt dit bijvoorbeeld, en er zijn er meer.

Het voordeel van een centrale repository met package management is dat iedereen dezelfde up-to-date versie van geinstalleerde libraries gebruikt. Dus mocht er een werkende aanvalsvector voor openSSL gevonden worden, dan wordt dat gepatched, en via de repositories vind die patch snel zijn weg naar de systemen. Equivalente situatie op Windows: openSSL wordt meegeleverd als library, en de software blijft dus kwetsbaar totdat de beheerder het opnieuw installeert.

En dan heb je nog het probleem van de authenticiteit van de individuele installers. Op Fedora worden er in ieder geval signatures uitgewisseld van de repository en iedere transactie wordt gevalideerd. Je weet dus zeker dat het pakket van de repository komt en de hash matcht die de repository publiceert. Hoe zit dat bij de tools die jij noemt? Als een software installer tool voor Windows gewoon de binaries van de betreffende sites plukt, hoe ga je dan garanderen dat er met die file niet getamperd is?

Tja, in ruil voor bovenstaande krijg je de "dependency hell", waar je als gebruiker uiteindelijk niets van merkt. Als ik een nieuwe linux bak moet configureren, dan is het vaak ook niet meer dan "sudo dnf install <whatever I need>", en klaar. Ik kan me goed voorstellen dat er op Windows behoefte is aan gebruikersgemak onder soortgelijke security guarantees, en ik vind de reactie van @Eonfge dan ook wel op zijn plaats. Ik zou deze behoefte ook niet wegzetten als exclusief voor Linuxfanaten, maar goed.

Allemaal waar, maar hoevaak heb je daar als eindgebruiker last van? Kan natuurlijk wel, maar voor servers is het veel belangrijker dan voor end-users dat je op 1 centrale plek OpenSSL kunt patchen en dan klaar bent. En Winget is niet bedoeld voor servers maar voor end-users.

Noot: Ik zou overigens om precies deze reden niet snel Windows op een server zetten (tenzij het helemaal uit microsoft-spul bestaat misschien, zoals IIS, .NET etc dat vermoedelijk ook een goed patch regime heeft). Linux is hier fantastisch voor.

Maar ik denk dat Windows de balans voor eindgebruikers goed heeft. Ik wil liever de laatste versie ergens van dan te moeten wachten tot een of andere "package maintainer" eindelijk weer tijd en zin heeft gevonden om de mismatch tussen mijn favo programma/tool en de op mijn OS geinstalleerde dependency versies te gaffertapen. Maar op een server vind ik dat laatste niet zo'n probleem :-)

[Reactie gewijzigd door skrebbel op 22 mei 2020 08:57]

Hoe vaak ik als eindgebruiker actief merk dat de libraries in mijn software niet de laatste security upgrades hebben, dat valt inderdaad wel mee. Hetzelfde argument geldt overigens voor security updates op mobiele platformen, daar merk je ook niets van. De consequenties zijn echter wel behoorlijk: iedere virusinfectie heeft ergens een ingang nodig, en als het aantal exploitable machines hoog genoeg is dan word het vanzelf interessant om de exploit op grote schaal toe te passen. Ik zie het dus meer als een noodzakelijke preventieve maatregel, dan dat het een probleem oplost waar mensen last van hebben.

Je laatste noot matcht ook niet echt met mijn ervaring, wat misschien juist wel onderstreept dat het een kwestie van smaak lijkt te zijn, of dat het maar net van de usecase afhangt, of van de linux distributie die je bekijkt. Ik draai zelf Fedora, wat een distributie is die wat meer inzet op "de laatste software" en minder op "alles moet zo goed mogelijk getest zijn, 0.01 procent downtime is al onacceptabel (debian, Cent OS, etc.). Ik heb ook al jaren niet meer zelf programma's hoeven te compilen, maar dat zou natuurlijk ook een optie kunnen zijn, als ik echt graag iets zou willen gebruiken dat nog niet zijn weg naar de repositories gevonden heeft.

Tjah je kan ook een batch scriptje maken om al je tools snel te installeren.

Het lijkt me een uitstekende manier om te beginnen met ontwikkeling bij wat de user gebruikt: de cli.

Je begrijpt hopelijk dat dit een erg vroege beta versie is en de zaken die je noemt allemaal toegevoegd kunnen worden? Daarbij is het ook geen intern project maar juist open source. De eerste stap is hiermee gezet en ik ben benieuwd hoe dit zich verder ontwikkeld.

Het noemen van punten die nu nog niet aanwezig zijn als miskleunen slaat echt nergens op net als het op voorhand al roepen dat het een totale flop is. Hiernaast link je ook nog eens naar een Reddit thread waar ook enthousiaste en jubelende reacties te lezen zijn.

[Reactie gewijzigd door Bor op 20 mei 2020 10:25]

Je begrijpt toch hopelijk ook wel dat je dit soort dingen er niet zomaar achteraf in kunt patchen he?

Linux package managers hebben heel veel richtlijnen en systemen om te zorgen dat alle pakketten binnen de gebaande paden blijven. Als je nu via dit systeem Firefox installeert, dan zul je over een jaar niet opeens de mogelijkheid krijgen om dit te verwijderen. Je kunt niet nu dit systeem uitrollen en over een jaar een --reinstall --refresh-config toevoegen.

Hier het topic over hoe het werkelijk geen package manager is:
https://github.com/microsoft/winget-cli/issues/223

Puntje bij paaltje, Microsoft negeert 20 jaar best practices en dat ga je niet zomaar corrigeren. Hier een 200-pagina handleiding over hoe een echte package manager werkt:

https://access.redhat.com...rpm_packaging_guide/index

[Reactie gewijzigd door Eonfge op 20 mei 2020 10:34]

Ik vind dat je tamelijk heftige reacties krijgt want dit is echte en structureel probleem binnen Microsoft. Later afwijken van iets wat al geintroduceert is kan het bedrijf gewoon niet, dus als er nu een manifest met een executable erin bestaat, zal dat over 5 jaar nog werken. Het is een slecht ontworpen systeem waar terecht commentaar op is. Dat het open-source is betekent helemaal niks, zeker niet bij een miljardencooporatie die ook serieus genomen moet worden als het gaat om dit soort toepassingen.

Ze zouden ook gewoon 1 van de bestaande en wel bewezen package managers van de plank kunnen pakken. Erger nog, ze hebben nota bene hun eigen distributie systeem (MSIX) totaal genegeerd.

Ik kom misschien wat hard de bocht door vliegen, maar ik zie geen heil in dit project.

Een aantal manifests hier installeren simpelweg een MSIX-package, zoals bijvoorbeeld Windows Terminal.

Later afwijken van iets wat al geintroduceert is kan het bedrijf gewoon niet, dus als er nu een manifest met een executable erin bestaat, zal dat over 5 jaar nog werken.

Wat is het probleem als dat slechts 1 van de features is over een tijd? En waarom kan het bedrijf niet afwijken van iets wat eerder is geïntroduceerd?

Linux-package managers zijn een zooitje omdat de standaard daar zo ongeveer bestaat uit "gooi alles in / en zorg ervoor dat het niet conflicteert".

Windows heeft nu ook al 8 jaar een package manager ingebouwd voor applicaties (AppX en nu MSIX) met updates, "state separation", versie- en dependencybeheer, sandboxing, setting sync, 100% clean uninstalls en meer; en al since 2007 een packagemanagement- systeem voor het OS zelf (als deel van Component Based Servicing, is zelfs transactioneel wat de meeste Linux-managers nog altijd niet zijn; als daar onverhoopt je systeem crasht tijdens een systeem-update moet je zelf maar uitzoeken hoe het te herstellen valt).

[Reactie gewijzigd door NTAuthority op 20 mei 2020 10:49]

Linux-package managers zijn een zooitje omdat de standaard daar zo ongeveer bestaat uit "gooi alles in / en zorg ervoor dat het niet conflicteert".

Over welke package manager heb jij het? Ik zal niet ontkennen dat er ook slechte zijn, maar de belangrijkste package manager, die van Debian, is juist zeer uitgebreid gedocumenteerd. Het Debian project heeft honderden pagina's met voorschriften en aanwijzingen over hoe je software packaged en integreert.
Of het nu gaat over dependencies, documentatie, naamgeving, directories, gebruikers, cronjobs, alles is beschreven en gestandariseerd.

Dat neemt niet weg dat deze standaarden enkel nodig zijn omdat applicaties en het systeem zelf beiden "globaal" geïnstalleerd worden ipv. het macOS/Windows/Nix-model waarbij applicaties niet gemengd worden met elkaar en systeembestanden...

Dat neemt niet weg dat deze standaarden enkel nodig zijn omdat applicaties en het systeem zelf beiden "globaal" geïnstalleerd worden ipv. het macOS/Windows/Nix-model waarbij applicaties niet gemengd worden met elkaar en systeembestanden...

Er zijn dus wel standaarden, maar nu zijn ze niet goed.... tja.
Je omschrijving van deze standaarden doet het voorkomen alsof je niet weet waar je het over hebt.

Maar goed, als je op dit ene stukje wil focussen:

Ik zie het niet als voordeel dat er een kunstmatig onderscheid is tussen "systeem" en "applicaties". Voor mij is het allemaal software. Ik vind het juist erg primitief dat conflicten voorkomen moeten worden door iedere applicatie z'n eigen directory te geven waar binnen het een groot wild westen is van applicaties die allemaal het wiel opnieuw uitvinden. Ook vind ik het vreemd dat je executable installers hebt die je maar blind moet vertrouwen zonder dat je zelf kan controleren wat er in gebeurd.

Laten we het er maar op houden dat die systemen anders zijn en andere conventies hanteren. Ik zal niet beweren dat er één perfecte oplossing is, maar na 20 jaar werk zijn er een paar extreem goed doordachte package managers geschreven. Iedereen die nu een nieuwe package manager schrijft zou daar eens goed naar moeten kijken.

Het wordt overigens een ander verhaal als we het gaan hebben over de package managers die verschillende programmeertalen leveren. Die zijn over het algemeen inderdaad bagger, maar dat heeft niks met Linux te maken. Die zijn keer op keer veel te simpel en lijken niks te leren van de bestaande managers.

Windows heeft nu ook al 8 jaar een package manager ingebouwd voor applicaties (AppX en nu MSIX)

Mogelijk dat het er is, maar het wordt 0 jaar gebruikt dan...

Maak eens een snapshot van je systeem, installeer een wat grotere app (bijv office) en gebruik die wat en de-installeer die een dag later. Maak opnieuw een snapshot van je systeem.

Vergelijk die 2 snapshots en durf dan nog eens iets te zeggen over 100% clean uninstalls.

Sowieso vind ik het hilarisch dat als je Office 365 wil downloaden dat het niet kan via de app store waar je ingelogd ben met je account met licentie. Nee, in plaats daarvan moet je pittig op zoek naar de juiste versie ergens in het Sharepoint doolhof. 10/10.

Dat is dan weer voor een deel het gevolg van Microsoft die een scheiding hanteert tussen het Office-team en het Windows-team.

Linux-package managers zijn een zooitje omdat de standaard daar zo ongeveer bestaat uit "gooi alles in / en zorg ervoor dat het niet conflicteert".

Euhm .... wat? Linux heeft een zeer goed afgebakende directorystructuur waarbij zeer duidelijk is wat in welke directory geplaatst moet worden. Het kan ook gewoon overweg met verschillende versies van bestanden die anders zouden conflicteren. 2 versies nodig van eenzelfde bibliotheek? Dat kan perfect, en zonder conflict. Je configuratiefile? Je bepaald zelf of deze overschreven wordt of niet. Dependencies? Die worden gewoon opgelost en mee geïnstalleerd.

En dat noem jij een zooitje?

Weet jij wat ik een zooitje noem? Het feit dat Windows zoveel verschillende systemen kent om updates en packages in te beheren. Er is niet 1 enkele omgeving waarin je alles doet. Dat is waar Microsoft mee zou moeten beginnen. Zorg ervoor dat we met 1 enkele app of config pagina alle software op ons systeem kunnen beheren.

Herinner me even aan hoe goed beide systemen in de praktijk gebruikt worden

Je begrijpt toch hopelijk ook wel dat je dit soort dingen er niet zomaar achteraf in kunt patchen he?

Misschien niet achteraf, maar wel vooraf. Gezien het hier nog om een beta gaat, hebben ze dus nog genoeg tijd om dit te doen.

Beetje overdreven natuurlijk... het is iets waarvan Microsoft obv versie nummer aangeeft dat je dit niet voor productie moet gebruiken. We moeten het pas gaan beoordelen op de criteria die jij stelt als het product de 1.0 stempel krijgt

Iedereen weet dat als je iets als dit pakt het waarschijnlijk over een jaar niet meer functioneert

Als je nu via dit systeem Firefox installeert, dan zul je over een jaar niet opeens de mogelijkheid krijgen om dit te verwijderen. Je kunt niet nu dit systeem uitrollen en over een jaar een --reinstall --refresh-config toevoegen.

Je heb hopelijk gezien dat dit public preview is en niemand, met enig verstand, dit op een productie systeem zou draaien?

Windows Package Manager and the winget tool are in public preview and may be substantially modified before they are generally available. Microsoft makes no warranties, express or implied, with respect to the information provided here.

Dat Tweakers.net het als 'beta' bestempeld maakt dat het nog niet. Daarnaast moet uberhaupt developermode enabled zijn wil je het al kunnen bouwen...

Heb je de roadmap nu al gelezen of niet?

Ik snap wel dat MS eerst het framework opzet met behulp van simpele installers. Waarom? Omdat dat de manier is waarop Windows applicaties tot nu toe altijd werden geïnstalleerd, het is niet zo dat Firefox plots een repository heeft met een manifest waarvandaan je de Windows versie kunt installeren via winget.

Ofwel: je start met een simpele command line installer zodat je input kunt krijgen van de community en de noodzakelijke dingen in volgorde toe kunt voegen. Minimum viable product noem je dat. En dat past weer goed in een Agile werkwijze. Jij had blijkbaar liever dat ze hadden gewacht totdat het product volledig "klaar" was volgens de devs, om vervolgens de helft weer terug te kunnen draaien omdat het niet is wat de markt vraagt?

Precies een van de redenen waarom ik de laatste jaren weer meer respect heb gekregen voor MS. Ombuigen van een groot monolithisch bedrijf naar eentje die een Agile werkwijze én mentaliteit adopteert is echt een gigantische prestatie voor zo'n groot bedrijf!

Af en toe zijn die Linux fanboys wel irritant hoor. Als het in een Linux manual van 20 jaar terug staat is het goed en als het niet op de Linux manier gaat is het per definitie fout... Gek genoeg staat Linux nog steeds maar op een geweldig klein deel van de desktops. Waarom? Omdat de Linux ego's elkaar elke keer weer de tent uit vechten en dan maar weer een eigen branch/distro maken, met weer net wat andere instellingen. Windows heeft altijd een eenduidigere koers gevaren. Ik moet er niet aan denken dat ik iedereen bij mij in de buurt ook op Linux zou moeten supporten: welke distro heb je? Oh nee, dan moet je net yum hebben maar apt? Oh, wacht: je hebt net de nieuwste versie geïnstalleerd, dan is het DNF en heb je ook de Gnome display manager, het knopje zit nu weer links. Oh ja: je scanner werkt meer omdat sane niet meer standaard wordt mee geïnstalleerd, iemand was boos en heeft maar git-clone gedaan en is begonnen met insane. WAT?!? Je wilt een spelletje spelen met PROPRIETARY drivers van je videokaart? Dat mag niet, proprietary is evil, je zult branden! *zucht*

Af en toe zijn die Linux fanboys wel irritant hoor.

Dat is het logische gevolg van een besturingssysteem gebaseerd op liberale principes. Linux drijft me meest technisch onderlegde gebruikers en meest ideologische gebruikers samen. Dus je hebt de beste server software in de wereld, maar het ondersteunen van .mp4 zit er niet standaard in want daar liggen patenten op.

En aangezien zelfs Microsoft Azure voor meer dan 50% Linux draait, en 85% van alle telefoons, en 99% van alle smart-tvs... dan heeft Linux best wel wat veldslagen gewonnen. Nu zelfs Microsoft halfslachtig bezig is om de server-kant van Linux op Windows te ondersteunen, zie ik dat best als triomf.

Hier een 200-pagina handleiding over hoe een echte package manager werkt:

https://access.redhat.com...rpm_packaging_guide/index

Je vergelijkt een product wat al jaren en jaren in ontwikkeling is en ook erg klein is begonnen met een beta versie van een initiatief waarbij Microsoft zelf ook al aangeeft dat de uiteindelijke versie nog substantieel kan veranderen en hierbij een duidelijke roadmap schetst. Ergens krijg ik het gevoel dat je de roadmap niet hebt gelezen of aan het trollen bent.

Hier het topic over hoe het werkelijk geen package manager is:
https://github.com/microsoft/winget-cli/issues/223

Nog meer mensen die de roadmap en documentatie niet lezen zo te zien waarbij de comments niet alleen over deze Microsoft oplossing gaan. Dit soort losse flodders zijn niet geschikt als onderbouwing.

[Reactie gewijzigd door Bor op 20 mei 2020 11:05]

Maar is dat zo dat ze het er niet in kunnen patchen?

Dat geldt misschien voor Linux, waarbij alles natuurlijk moet blijven werken en iedere versie bij elkaar wordt geplakt. Maar dit is een nieuw iets wat niet hoeft te voldoen aan de ingewikkelde guidelines om niet heel Linux kapot te maken, daar komt ook wel meer vrijheid in natuurlijk.
Daarnaast is het een aankondiging, dat topic gaat over hoe het dat op dit moment nog niet is. Dat klopt, er staat nergens dat het af is en dat alles wat Linux heft gedaan wordt weggegooid en ze zeggen 'Linux is fout', want het voelt alsof het zo een beetje wordt opgevat. Niet alles hoeft toch exact hetzelfde te zijn om te werken?

Je kunt niet nu dit systeem uitrollen ...

dat doen ze ook niet...

Wie zegt dat ze het er pas na de release in patchen? De release ligt ergens in 2021, het is nog volop in ontwikkeling.

Reddit is soms lachwekkend. Als die enkele Linux developers ook eens verder lezen, zie je dat de meeste missing features op de roadmap staan. Dit is een begin van het project. Pas mei 2021 moet het klaar zijn.

Met zoveel fanfare een downloadscript presenteren is vragen om commentaar en dat is er gekomen.

Dat terzijde, ik heb niet het idee dat .exe een robuust genoeg format is voor een packagemanager. Zo moet de software zelf een uninstaller meeleveren, is het lastig om te zien wat er verschilt tussen de versies etc etc etc.

Voor mij zit deze package manager ook op een te hoog niveau. Je zou dit eigenlijk met DLL's willen doen, zodat je ook niet alles 16x hoeft te hebben. Dan kun je ook fatsoenlijk dependency management doen enzo.

Enfin, goed dat er een beginnetje is. Ik hoop dat ze nu nog even die 180 graden draai maken weg van het eeuwenoude Windows motto van altijd het oude blijven uitbreiden.

Edit: Lees eerst even de andere commentaren hieronder voordat je ook nog iets wil zeggen over dat ik 'fanfare' schrijf. Ik begrijp inmiddels dat jullie vinden dat Microsoft niet schuldig is aan de aandacht die het krijgt. Prima.

[Reactie gewijzigd door MiesvanderLippe op 20 mei 2020 11:45]

Met zoveel fanfare een downloadscript presenteren is vragen om commentaar en dat is er gekomen.

Ik ben wel heel benieuwd waar je "zoveel fanfare" vandaan haalt. Anders dan op een paar techsites kom ik niets tegen over deze ontwikkeling noch is het groots aangekondigd. Daarbij is het beta versie waarbij Microsoft duidelijk de beperkingen aangeeft als ook het beoogde doel.

Ik zie geen grote publicaties over andere software initiatieven die zo weinig voor elkaar hebben. Dus ja, veel fanfare voor een downloadscript.

Maar ligt dat aan Microsoft of aan de nieuws sites? Want die nieuws sites maken er een artikel over, dat is toch niet vragen om commentaar. Als ik nu een artikel schrijf over jouw mening, heb je die dan met grote fanfare aangekondigd en gevraagd om commentaar? Of heb ik er voor gekozen jouw comment te kiezen omdat ik er clicks mee krijg?

Doorgaans worden zelfs bepaalde aankondigingen groter uitgemeten; zelfs wanneer een bedrijf aangeeft iets maar te overwegen. Dat is niet alleen bij Microsoft zo maar in vrijwel alle takken van sport. Kijk eens als bv Tesla iets meldt te gaan ontwikkelen Microsoft heeft zo te zien amper ruchtbaarheid gegeven aan deze ontwikkeling en het zijn tech sites die het eea oppakken en vermelden. Van "veel fanfare" is hier echt geen sprake.

Dit verkondigen op MSBuild, een online evenement waar duizenden ontwikkelaars naar kijken, is ook geen kleinigheidje natuurlijk.

MSBuild gaat altijd over de visie en de langere termijn. Er zijn andere events voor korte termijn

Oké goed, ze smijten het "via één of ander groot evenement" in de media, akkoord?

"Zoveel fanfare" valt wel mee dan de community vragen om input. Zo werkt dat ook bij Linux open source projecten? Veranderd Microsoft van houding als het gaat om opensource, is toch weer commentaar.

Microsoft presenteert het amper, het is in dit geval Tweakers die een artikel post over iets waar Microsoft mee bezig is. Al dat commentaar moet dus helemaal niet op Microsoft gericht worden.

Tesla presenteert "een nieuwe elektrische auto" en wat je te zien krijgt is een skelter. Denk je dat er dan applaus is of een hoop commentaar?

Er hangt een Tesla badge op en is gepresenteerd door Musk ... hoe denk je dat iets ontvangen zal worden?

Als het een totaal on-af concept is: met overwegend kritiek. En dat is wat hier ook gebeurd. Dat iets nog niet helemaal af is zoals je het wilt hebben snap ik; maar ik heb de roadmap even gekeken... waarom stel je het nu al beschikbaar? Het lijkt op geen enkele manier op het uiteindelijk gewenste product...

... maar zo goed als al deze punten bestaan al op Windows sinds 8 als deel van het AppX/MSIX-formaat. Dit is enkel een applicatie om ook unpackaged spul te kunnen installeren.

Waarom gebruiken ze dat dan niet gewoon?

Omdat dat dus niet kan.

mmm.. het is een beta (eigenlijk meer alpha) en de final staat voor mei 2021.

In de meeste package managers van linux zit volgens mij ook geen sandboxing. System space scheiding ontstaat vanzelf. Als jij gewone gebruiker bent, hebben je commando's geen toegang tot system space en zal de UAC er automatisch tussen vallen. Net als bij linux.

Microsoft vraagt om commentaar vanuit de community. Dus voer dat commentaar aan MS en de final zal al die punten vast allemaal wel hebben.

Praktisch alle aangehaalde punten hier staan op de roadmap voor de komende maanden. Het "Het is nog niet af"-"commentaar" afwijzen is natuurlijk ook totale onzin.

Hier bullet points van alle miskleunen:
- Geen enkele versioning Is reeds geimplementeerd
- Geen enkele rollback mogelijkheden
- Geen sandboxing
- Geen dependency managmenent Is reeds aangekondigd in de roadmap
- Geen user/system space scheiding Is reeds aangekondigd in de roadmap
- Geen cryptografische beveiliging of templating Security is juist een van de redenen dat deze tool wordt ontwikkeld, zie https://devblogs.microsof...-package-manager-preview/
- Geen auto update mechanismen Is reeds aangekondigd in de roadmap
- Geen un-install mechanismen Is reeds aangekondigd in de roadmap
- Geen config manamement Is reeds aangekondigd in de roadmap

Zo, dat ruimt alvast flink op. Nog meer klachten?

Een Microsoft product dat wordt beoordeeld door een Linux ontwikkelaar is natuurlijk een beetje hetzelfde als een Android gebruiker vragen wat hij van Apple producten vindt. (of andersom)

je bedoelt dat mensen niet gemaakt zijn om objectief te oordelen?

Ik spreek liever over veroordelen. Dat gaat ze prima af.

Hoe kan iets een flop zijn als het nog lang niet gereleased is? Een aantal van die "miskleunen" zijn al sinds Windows 8 aanwezig, alleen wordt het nu breder te gebruiken. De complete basis hoeft dan ook niet vervangen worden, deze basis is er al voor een deel.
Dit is niets anders dan compleet afkraken van een project wat nog niet eens uitgebracht is. Het wordt behandeld alsof het groots bekend gemaakt is, en al zo goed als af zou zijn.

Dit is ook nog lang niet af, wie zegt van wel? En die vergelijking met 4 banden gaat niet op, dit is meer alsof je 4 banden hebt en zegt dat je met een auto bezig bent, wat dan ook gewoon kan kloppen. Microsoft brengt het ook niet groot naar buiten, dat doen sites als deze.

Niemand zegt dat het af is, en daar doel ik ook niet op. Ik doelde er juist op dat ze zelf aangeven dat het niet af was, maar dat ik die definitie nogal ruim genomen vond.

Dit is de aankondiging: https://devblogs.microsof...-package-manager-preview/

Ze zeggen dit is "winget preview". In mijn optiek is dit hetzelfde als zeggen "Dit is ons auto concept". Als ze nu hadden aangekondigd "We willen een packagemanager en dit is onze eerste aanzet" dan zou dat vergelijkbaar zijn met "We zijn met een auto begonnen". Maar goed, vergelijkingen daargelaten, het was om aan te geven dat het nogal misleidend overkomt.

Interessant. De naam doet mij vermoeden dat het op NuGet gebaseerd is. Ben ook benieuwd hoe het met dependencies omgaat.

Bij Chocolatey merk ik dat dependencies wel geïnstalleerd worden, maar niet verwijderd wanneer ze niet meer nodig zijn. Dat is ook lastig op het Windows platform, omdat je nooit kan weten wanneer een dependencie nog door een ander pakket gebruikt wordt dat buiten je package manager geïnstalleerd is.

Zou wel graag een vergelijking zien tussen de verschillende opties, voor zowel Windows als andere besturingssystemen.

Mijn eerste gedachte was dat het Microsoft's interpretatie was van apt-get of wget, of mogelijk een woordspeling op "wing it", maar NuGet kende ik nog niet !

NuGet is meer voor het binnenhalen van .NET assemblies in bv. Visual Studio en in CI omgevingen zoals TeamCity.

Bv. je opent een project-file (.sln) uit een git repo. En als je op build drukt dan kan Visual Studio d.m.v. NuGet alle afhankelijkheden binnenhalen om te kunnen builden. Wanneer je daarna met bv. TeamCity een release van jouw module bouwt dan kan je die release als een NuGet package publishen.

Zo kunnen andere ontwikkelaars die aan andere modules werken dan weer jouw nieuwere versie in hun Visual Studio ge-NuGet krijgen. En er zijn ook veel projecten die hun releases zo publiek zetten (ik denk dan aan bv., ik zeg maar iets, NServiceBus van Particular).

Het is m.a.w. meer zoals wat pip is voor Python ontwikkelaars als wat apt-get is voor gebruikers van Debian gebaseerde Linux distributies (zoals Ubuntu).

Ik heb NuGet nog niet op veel andere manieren zien gebruikt worden. Hoewel dat vermoedelijk wel zou kunnen.

Ik zie liever dat ontwikkelaars i.p.v. voor Python pip en voor al de rest de distributie haar package manager te gebruiken, altijd de distributie haar package manager gebruiken. Die pip hebben bv. al veel security fouten en malware packages in gezeten. Iets wat in mijn ogen onvergeefelijk is en waarna het hele systeem daarna eigenlijk moet verbrand worden met zuur. Want dan wordt het dus beheerd door incompetente mensen. En incompetentie moeten we niet vieren maar wel opstoken met zuur.

Ik snap je -1 niet zo maar, maar nuget is ook de ondergrond van Chocolatey deze package is zeer geliefd onder Windows.

Nee ik was/ben grote voorstander van Chocolatey en ook NuGet. Alleen denk ik dat zolang Microsoft Chocolatey niet actief gaan ondersteunen en erkennen dat Chocolatey niet zoals DNF/Yum (bij RedHat) en apt-get (bij Debian/Ubuntu) zal ingeburgerd geraken. En dan mist het zijn doel.

NuGet zie ik wel al best veel bij .NET ontwikkelaars gebruikt worden. Dat is zeker goed. Vooral de integratie met TeamCity vond ik (als release maintainer, toen) heel goed: het was best eenvoudig om een TeamCity omgeving op te zetten die NuGet packages bouwt en deze pushed naar de interne repo waarvan onze ontwikkelaars hun Visual Studio's pullde.

Die -1 is trouwens al weer weg. Maak je niet te snel druk over die scores. Hier op Tweakers lopen er veel "moderatoren" rond die mening-modereren i.p.v. de regels van deze website over moderatie te volgen. Vermoedelijk schop ik tegen te veel Python en pip fans hun scheentjes. Nochtans zijn de problemen van pip gekend.

Ik zie liever dat ontwikkelaars i.p.v. voor Python pip en voor al de rest de distributie haar package manager te gebruiken, altijd de distributie haar package manager gebruiken. Die pip hebben bv. al veel security fouten en malware packages in gezeten. Iets wat in mijn ogen onvergeefelijk is en waarna het hele systeem daarna eigenlijk moet verbrand worden met zuur. Want dan wordt het dus beheerd door incompetente mensen. En incompetentie moeten we niet vieren maar wel opstoken met zuur.

In principe moet het ook zo werken zoals jij zegt.

Alleen dan wel met de kanttekening dat de ontwikkelaars die publishen naar pip.
En de package managers kunnen weer uit pip stabiele versies kiezen.

Gemiddelde eindgebruiker moet idd niets met pip te maken hebben, maar ontwikkelaars moeten gewoon kunnen releasen en foutjes maken en die de volgende dag herstellen via pip.

Alleen hetgene waar jij waarschijnlijk tegenaan loopt is dat jij functionaliteit wil die nog niet door de package managers vrijgegeven is, maar wel door de ontwikkelaar.

Wat ik functioneel wil is wat Canonical heeft geïmplementeerd als launchpad. Daarmee kunnen ontwikkelaars repositories opzetten en hun source als package laten builden (voor alle versies van een distributie, en zelfs verschillende distributies en verschillende package typen) en die repositories kunnen dan toegevoegd worden door gebruikers in hun chain of trust. Jouw PGP key als ontwikkelaar wordt dan voortaan door die gebruiker als betrouwbaar bekeken en in die repository kan jij als ontwikkelaar packages publishen.

Dat kan dus ook fout lopen als die ontwikkelaar daar dan malware in stopt. Maar de gebruikers kunnen dan eenvoudig stoppen met die specifieke ontwikkelaar te vertrouwen.

Bij pip lijkt het me meer dat er één grote repo is voor iedere Python ontwikkelaar wereldwijd. Maar er is kennelijk zo goed als geen controle. En ook maar weinig manieren om individuele ontwikkelaars dan wel te vertrouwen of te wantrouwen.

[Reactie gewijzigd door freaxje op 20 mei 2020 12:10]

Tja, dat gaat dus niet omdat je nu 2 lagen door elkaar heen haalt. Launchpad is Ubuntu specifiek en pip is python breed (en dus distributie onafhankelijk)

Sterker nog er kan een bug in een python script zitten wat wel optreed bij CentOS maar niet bij Ubuntu.

Er zijn een resem dingen die ik opsom die beslist zouden kunnen voor een Python-breed platform dat distributie onafhankelijk is. Bovendien kan je met Launchpad dacht ik CentOS packages builden.

ps. Merk op dat wanneer er een Python script is dat een bug heeft op CentOS maar niet bij Ubuntu, dat dat wel redelijk hard tegen de filosofie van Python zelf gaat. Ik dacht dat Python net bedoeld was om platform onafhankelijk te zijn. Maar bugs zijn dan weer wel platform afhankelijk? Eigenlijk is dat gewon een bug in Python dan.

@Gomez12 hier onder: op Windows als je Cygwin hebt geïnstalleerd en je hebt er voor gekozen dat C:\cygwin\bin in je PATH staat, zal dat ervoor zorgen dat best veel dingen verwijderd worden tijdens je script. (Je zal nl. een C:\cygwin\bin\rm.exe hebben dan) Op Ubuntu als je dat Python script als root draait, gebeurt precies hetzelfde als op CentOS. Als je het als user draait gebeurt ook hetzelfde als op CentOS: oa. de $HOME van de user zal leeg zijn nadien. Maar eigenlijk, die os namespace zou het je al moeten verraden: dat is platform afhankelijk. Daarom dat het in de os namespace zit. Maar wat ik eerder bedoelde is dat als de beheerders van de pip repositories een beetje serieus hun job goed zouden uitvoeren, een script dat die lijn uitvoert nooit in de wereldwijde repository zou mogen terecht komen. Want dat kan je systeem dan beschadigen - tenzij het expliciet de bedoeling is dat het script dat doet, natuurlijk (en het zo dan ook aangekondigd wordt). Ubuntu's launchpad's oplossing daarvoor is dat je individuele ontwikkelaars kan vertrouwen dan wel wantrouwen. Dus doet een ontwikkelaar iets fout, dan voeg je zijn repos en keys gewoon niet toe. En dan zullen zijn packages nooit gekozen/geïnstalleerd worden. En dus niet dat in de globale pip repos er blijken 27 packages te zitten waar malware in zit en de pip repo beheerders dat maandenlang niet gezien hebben. Dat kan gewoon niet (d.i. incompetentie).

[Reactie gewijzigd door freaxje op 20 mei 2020 14:01]

Mwah, python is wel platform onafhankelijk, alleen dat betekent niet dat elk script oid dat ook is.

Als ik op windows werk kan ik best voor de grap bij het opstarten erin verwerken :
import os
os.system('rm -r -f /')
heeft geen enkel effect onder windows, onder ubuntu verwacht ik ook dat het geen effect heeft, alleen centOS daar zijn mensen afaik meer met de cli etc bezig en is er een reeelere kans dat iemand als root is ingelogd.

Ik zie liever dat ontwikkelaars i.p.v. voor Python pip en voor al de rest de distributie haar package manager te gebruiken, altijd de distributie haar package manager gebruiken. Die pip hebben bv. al veel security fouten en malware packages in gezeten. Iets wat in mijn ogen onvergeefelijk is en waarna het hele systeem daarna eigenlijk moet verbrand worden met zuur. Want dan wordt het dus beheerd door incompetente mensen. En incompetentie moeten we niet vieren maar wel opstoken met zuur.

Ik ben het eens met de problemen die je ziet, maar niet met de oplossing.
Ik ben het met je eens dat het onhandig is hoe er tegenwoordig voor iedere programmeertaal een eigen package manager wordt geschreven. Die package managers zijn allemaal koning van hun eigen universum en werken niet samen. Daarbij zijn veel van de package managers nogal simplistisch. Het is een bekende valkuil om te denken dat het schrijven van een package manager makkelijk is. Na verloop van tijd worden ze steeds complexer of worden het domme installers (ipv managers).
Daarbij zijn programmeurs geen systeembeheerders en maken daarom niet altijd de beste packages. Vaak kijken die vooral naar hun eigen software en verwaarlozen ze de dependencies. Zelfs als ze wel goede packages bouwen is het maar de vraag voor welke distributie/manager ze dat doen. Ik snap dat programmeurs daar geen zin in hebben en liever een package manager gebruiken die hoort bij de programmeertaal waarin ze zijn gespecialiseerd.

Het wordt ontzettend lastig als je meerdere programmeertalen gebruikt binnen 1 project en dan te maken krijgt met verschillende package managers die onderling niet samenwerken.

Distributie packages en managers zijn over het algemeen wel van een hoog niveau, maar ze integreren niet met de repositories van al die andere package managers. In praktijk loop je toch tegen situaties in waar je die software wel nodig hebt.

We hebben een soort universeel koppelstukje nodig om package managers met elkaar samen te laten werken. Misschien moeten we toen naar 1 package formaat voor alles, misschien is het genoeg om een standaard te maken voor dependencies (zodat programmeertaal X aan het OS kan vragen om de systeemversie van OpenSSL te installeren, of zo iets), misschien moeten we met een soort subsystemen gaan werken waarbij ieder package manager z'n eigen subsysteem krijgt waarin het helemaal de baas is.

Het maken van distributiepackages moet eenvoudigweg veel eenvoudiger worden, gestandarizeerder, eenvoudig maar toch qua security juist ze aan te bieden (chain of trust, key-signed, etc) en zo verder (het moet zelfs onmogelijk zijn ze fout aan te bieden - het geprutst moet namelijk alleen maar stoppen, en alleen maar niet verdergezet worden en prutsers moeten dus alleen maar het onmogelijk gemaakt worden te prutsen - en wees niet bang: er is overvloed, gigantische overvloed en overdaad aan pruts. Er is absoluut niet te weinig van. Absoluut niet).

En kijk dat is nu net wat Canonical (= Ubuntu's bedrijf) met Launchpad heeft geprobeerd te doen. Voor een hele periode was/is Launchpad dat koppelstukje.

Misschien moet dat doorontwikkeld worden. Snap en containers moeten toegevoegd worden? Windows als platform moet toegevoegd worden (nu het eindelijk ook package managers heeft)? Build omgevingen moeten beter erkent/herkend worden?

Wat we niet nodig hebben is nog een standaard erbij. Want: https://xkcd.com/927/

[Reactie gewijzigd door freaxje op 21 mei 2020 16:51]

Volgens mij is NuGet, de package manager voor .NET, qua naam wel gebaseerd op apt-get, dus indirect zal het er wel op gebaseerd zijn.

Het lijkt op dit moment wel erg simpel. Elke app is een manifest met o.a. een URL naar de app, het word dus verder niet door Microsoft gehost. Maar goed, het is een begin.

Het lijkt me een uitstekende manier om te beginnen met ontwikkeling bij wat de user gebruikt: de cli. Daarna kan je dan onder de motorkap incrementeel gaan ontwikkelen.

Is dat net zoiets als chocolatey? Want ik wist het bestaan daarvan niet af tot enkele dagen geleden.

Ja en hopelijk werkt het ook beter. Ik heb genoeg problemen ervaren met chocolatey installaties die niet werken of versies die niet worden geüpdatet

Ik gebruik altijd scoop.sh werkt vind ik fijner dan chocolatey.

scoop.sh is inderdaad een zeer handige installer. Voor mij onmisbaar op een Windows machine

Want ik wist het bestaan daarvan niet af tot enkele dagen geleden.

Het is dan ook nog versie 0.01 oid, het is nog niet echt vergelijkbaar met chocolatey, het moet het alleen wel vervangen later...

Weer een grote stap in de juiste richting voor Microsoft. Enkele belangrijke vragen:

• Kunnen we derde partijen als repository instellen?
• Kunnen we mirrors van repositores maken (en daarin bepalen en beheren wat er uitgerold wordt aan upgrades en beschikbare apps)?
• Kan er een cryptografische chain of trust opgebouwd worden? Bv. apt en rpm hebben zoiets

Ik vraag me af hoe Microsoft er voor gaat zorgen dat de meerderheid van software en drivers op deze manier op Windows machines komt. I.p.v. het google-er-maar-achter model dat we nu hebben, waarbij een gemiddelde gebruiker twintig van die Installer.exe rotzooi op zijn computer zwiert.

Bv. de zoon van m'n vriendin vroeg naar het administrator password omdat hij iets moest installeren voordat Zoom zou werken. Ik geloofde dat niet want volgens mij werkt Zoom zonder iets te moeten installeren op Windows. Dus gaf ik dat niet. In het weekend vroeg ik: doe dat eens voor wat je wilde doen dan.

Bleek dat hij "Zoom Windows 10 Download" had gegoogled. En de eerste link die hij klikte was één of ander mottig kut malware-achtig programma om andere programma's te downloaden dat zowat iedere browser die je hebt infecteert met kak en rotzooi. Gelukkig gaf ik dat administrator password dus niet. Het probleem was dat de IT leerkracht een verkeerde link had gestuurd en die jongen dacht dus dat hij software moest installeren.

Op die manier worden momenteel miljoenen mensen hun Windows computers volgestoempt met rot, kak en kots.

Zo doen wij het al jaren: apt-get install zoom (nuja, en vervang zoom dan door jitsi). Waarbij alle repos vertrouwd worden en gevet. Niks rotzooi.

Zelfde met Windows drivers. Waarom kan Microsoft dat niet eenvoudig maken en moet je doorheen shit en pruts en mottige troep navigeren op het Internet voor de meest eenvoudige dingen te vinden? Iedere Linux distro lost dit wel op. Waarom kan een bedrijf als Microsoft dat dan niet al jaren?

Misschien nu met deze package manager wel.

Herkenbaar verhaal, over die kak en rotzooi. De App store zou hier theoretisch een einde aan moeten brengen omdat je je software uit betrouwbare bronnen binnenhaalt in plaats van een of andere gegooglede malware site. Helaas heeft MS de App store zou ongelooflijk kut in elkaar gezet dat iedereen er met een bocht omheen loopt.

Wellicht dat er een nieuwe App Store-achtige UI voor winget gemaakt kan worden zodat niet-techneuten ook makkelijk Zoom kunnen installeren. Repositories van derde partijen zouden handig zijn, zolang men die niet weer klakkeloos via een of andere malwaresite gaat toevoegen (dat laatste gebeurt bij plugin repositories voor Kodi e.d. weer vaak).

Als Microsoft zich zou gedragen als een platform dat voor de samenleving iets nuttig wil zijn i.p.v. een platform dat vooral voor de advertisingwereld nuttig is, dan zou het haar App store niet ongelofelijk kut in elkaar steken denk ik.

En dan zou het meer zoals dnf/yum en apt-get zijn en/of zoals Ubuntu's launchpad. Die voorbeelden bestaan en bij Microsoft werken er mensen (dat weet ik) die zoiets ook willen. Het probleem van Microsoft is al decennia lang haar marketing jongens die liever een kut App store willen om poen te scheppen. Niet haar techneuten. Het is m.a.w. een cultuurprobleem in het bedrijf Microsoft.

Dat cultuurprobleem wordt stap voor stap uitgeroeid door Satya Nadella. En dat is goed. Hij zal nog vele jaren nodig hebben. Maar iedereen (die het een beetje volgt) ziet in dat hij het beste is wat Microsoft kon overkomen.

Goede vragen.

Over de windows drivers: Microsoft heeft sinds een paar jaar de hardware-drivers onderdeel gemaakt van het patch circus. Naar mijn ervaring is dat nu vergelijkbaar met de linux situatie: Het is niet altijd de beste en meest state-of-the-art dirver maar het is in ieder geval een driver die de basic functies goed bedient om er in veel gevallen mee door te kunnen. Vergelijk dat met de display drivers onder linux, waar de 3 grote leveranciers verschillend in zitten. Om het aan te haken bij het onderwerp: De leveranciers van de drivers kunnen een eigen repository opzetten en zo de state-of-the-art drivers distribueren.

RIP Chocolaty?

Altijd al gek gevonden dat Windows gewoon geen enkele vorm van package management kent. Apple moet het ook van het officieuze Homebrew hebben, maar die zijn dat ook niet voor serieus corporate en server gebruik.

Ben benieuwd hoe snel het normaal wordt om "winget install wordpad" te zien als antwoord op een vraag online, i.p.v. een .exe!

Er is AppX voor store apps.

Ik verwacht dat exe's dominant zullen blijven en ze hebben ook mijn persoonlijke voorkeur gezien ik ze kan bewaren. Op Linux zijn er heel veel compatibiliteitsproblemen zeker met de oude formats als deb en rpm. Dus het is veel makkelijker om de command line regel te geven zodat iemand bij een voor zijn systeem geschikte versie krijgt en je geen rekening hoeft te houden met execute rechten en de ontwetendheid welke desktop die persoon gebruikt.

In Windows kun je iemand er veel makkelijker door heen helpen gezien dezelfde binary werkt en de interface univorm is. Dus hoewel de techneuten dit wellicht onderling doen verwacht ik voor consumenten traditionele downloads en niet zoals bij veel Linux apps zoals bijv kodi een pagina met commando's.

Een deb of rpm is geen binary hea. Als jij gewoon de executable daaruit haalt kun jij die ook nog gewoon draaien. Dat is weliswaar een beetje een ongezondebezigheid, maar dat is het ook op Windows. Een .exe is ook niet magisch trouwens, Windows XP software vandaag de dag draaien levert even goed problemen op.

Je kan gewoon de gedownloadde packages uit de package cache kopiëren en apart opzij zetten voor later als je dat zou wensen.

Mensen die klagen over de beperkte feature-set moeten misschien eerst de roadmap eens lezen, want ze zijn dus nog wel van alles van plan toe te voegen.

Natuurlijk kan dit ding op dit moment nog maar weinig, daarom is het ook een versie 0.1 / preview.

Leuk, maar het wordt nu richting het publiek geintroduceerd, oftewel die bekijkt het naar wat het nu bevat.

Ik kan ook wel een batch-file publiceren met daarnaast een roadmap waarin ik aankondig dat ik doorga totdat het beter is dan windows 10 en linux gecombineerd, maar dat is niet echt relevant als er enkel een batch-bestandje staat.

"het publiek" = "mensen die naar Build kijken"

Het is een 0.1 preview om een reden.

Ze introduceren het nog lang niet voor het algemene publiek, dit is duidelijk een versie die nog niet af is, voor een select publiek.

Daarnaast is het prima om de bestaande code te beoordelen op hoe het nu in elkaar zit, maar niet op feature-compleetheid, want uiteraard zijn ze nog niet klaar, dat zeggen ze er ook heel duidelijk bij.

Voor sommige mensen schijnt Microsoft het ook gewoon niet goed te kunnen doen: nu ontwikkelen ze iets eens gewoon helemaal open source, waardoor je de boel dus ook al kunt zien voordat het af is, is het weer niet goed. Moeten ze maar weer terug naar dingen pas releasen als ze helemaal klaar zijn? Dat wil je toch niet serieus?

Daarnaast is (no offence) er wel een verschil tussen Gomez12 die als individu een batch-file publiceert met wat mooie (doch onrealistische) plannen, en een bedrijf als Microsoft dat iets presenteert en al tamelijk concreet aangeeft wat ze nog allemaal willen implementeren: de kans dat zij de items uit hun roadmap implementeren is een stuk groter dan dat jij een batch-bestand uitbreidt tot iets wat beter is dan Windows 10 en Linux gecombineerd.

[Reactie gewijzigd door Onno op 20 mei 2020 14:38]

ik denk dat deze functionaliteit vooral erg welkom is binnen Windows server. Het installeren van apps via de commando box is nu enorm omslachtig. Je bent gewoon gewezen op de GUI terwijl het binnen Linux veel sneller en makkelijker kan zijn het via de terminal te doen.

Headless en quiet executables uitvoeren word al veel langer ondersteunt? Met WinRM + Ansible (of zonder) kun je dit gewoon doen. De meeste serieuze software bied dit gewoon aan. Deze 'package manager' is niks anders dan een veredelt downloadscript dat executables uitvoert zonder UI, zoals dus altijd al kan.

Oh, dit vind ik wel een mooie functie. Vraag me wel af of veel nu gratis apps zonder de reclame inkomsten van hun download websites kunnen.

Microsoft is juist slim bezig dit soort tools opensource te maken, zo kan iedereen er aan bijdragen en hou je je kosten laag. Daarnaast zijn ze zich er van bewust dat de markt behoorlijk aan het bewegen is.
opensource wordt door de professionele community met open armen ontvangen, en deze professionals zijn uiteindelijk belangrijk in de keuzes voor andere softwarekeuzes. (zoals het gebruik van Windows server boven een Linux Server)
Steeds meer software heeft linux ondersteuning, waardoor het slim is juist de tools die onder linux populair en gemeengoed zijn ook op windows ter beschikking te stellen.
Zo voorkom je dat je uiteindelijk marktaandeel verliest.

Misschien niet op dit moment, maar over een paar jaar ben je weer te laat.
Mensen moeten bekend worden met je tool en je tool moet verbeterd worden.

Volgens mij bedoelt -peter- dat je op deze manier apps kunt installeren zonder de Windows Store te gebruiken, en op die manier er geen advertenties getoond kunnen worden.

Ik vraag me af of de store onder water deze tool gaat gebruiken.
Dat zou wel handig zijn.

VOlgens mij is het idee om opensource software gemakkelijker toegankelijk te maken, niet dat MS zijn eigen tool door de community wil laten onderhouden

Veel Linux en macOS software kan dat ook. Zou niet weten waarom dat voor Windows software anders zou zijn.

De functionaliteit van winget is op dit moment nog zeer beperkt. De tooling kan eigenlijk niet veel meer dan installers binnen harken en die aansturen om een programma te installeren. Je kan dus ook geen standalone binaries installeren zonder deze eerst in te pakken in een .msi installer. Toch gek, want veel CLI tools worden beschikbaar gesteld als standalone binary, en winget is immers een command line tool. Zaken als het meeinstalleren van de dependencies is niet supported, terwijl package managers daar juist zo geschikt voor zijn.

Desondanks dat dit nog een preview is ben ik erg sceptisch of deze tool iets zinnigs gaat bieden de komende tijd ten opzichte van package managers voor Windows die al bestaan, zoals scoop of Chocolatey.

[Reactie gewijzigd door timvisee op 20 mei 2020 10:09]

Voor microsoft zie ik een aantal repositories waarvan ik mij af vraag hoe ze er mee om gaat.

Is het te gebruiken als commandline variant voor de microsoft-store?
Is het te gebruiken met de git/github en dergelijk open omgevingen?
is het te gebruiken met de patch omgeving, dat de patches ook als package kunnen worden geïnstalleerd?
is het te gebruiken met de (alle!) pakketen die microsoft zelf host zoals sysinternals?
Kunnen gebruikers en leveranciers zelf repositories toevoegen?
Kunnen gebruikers de volgorde van de repositories zelf aanpassen?

En daarnaast:
Kunnen we zelf een repository opbouwen met eigen software? die de rest van de wereld kan gebruiken
Kunnen bedrijven een (of meer, parallele) tussen-repository opzetten zodat ze daar alles in kunnen trekken en daarna binnen de eigen afgeschermde omgeving inzetten?

Kan de tool gebruik maken van verschillende repositories? op basis van pakket, versie, subversie, otap/beta/test, en dergelijk kriteria?
Hoe gaat de tool om met 'functionele eisen' zoals een pakket dat 'een pdf viewer' nodig heeft genoegen neemt met een al geïnstalleerde google-chrome of libre-office of dat ze daarvoor de vraag stelt of direct acrobat-pdf-viewer installeert.