Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing PackageManagement in Windows 10

blogs.technet.com

Post reply on HN
Print view View original

91–100 of 221 posts

Re: Introducing PackageManagement in Windows 10

#91

Post by mhurron »

tomswartz07 wrote: post #83
mhurron wrote: post #73

Earlier quoted context omitted.

The way around this is to update your deployment images from time to time. It's one reason I liked service packs, new service pack comes out, generate a new install image.

Right, and that takes care of the 'big ones', but you still have tons of other minor updates that are released every Patch Tuesday. I currently have Jenkins build an OS image every two weeks, just so our Deployment Server has an up to date image.

> I currently have Jenkins build an OS image every two weeks, just so our Deployment Server has an up to date image.

Ya, lots of tools have made this easier recently, but thinking about it, doesn't WSUS handle this?

I haven't been a Windows admin for a while, but I thought with WSUS it was install, join and forget while it did it's thing. Maybe it's been too long ...

Re: Introducing PackageManagement in Windows 10

#92

Post by zokier »

davexunit wrote: post #75
zokier wrote: post #39

Earlier quoted context omitted.

> Unifying multiple distinct package managers is a fool's errand I disagree. Why do you think that is the case?

Different package managers make different design decisions that make them incompatible with each other without sacrifice. Guix/Nix focus heavily on reproducibility and not relying on any third party binaries. These features would have to be thrown away if it unified pip, npm, etc. because they make no such guarantees. Every package manager works different, and trying to accomadate all of them with a unifying tool wil…

> These features would have to be thrown away if it unified pip, npm, etc. because they make no such guarantees.

Again I disagree. For example in this case, it would just mean that when installing from nix repos you get the reproducibility etc guarantees, installing from upstream repos would get you vanilla version and installing from OS repos would get you an integrated/patched version. But the installation process (from user point of view) could still be unified, because regardless what happens behind the scenes the high-level stuff is pretty much the same; nix -i/apt-get install/pip install could definitely be unified under one umbrella tool.

> I don't see a way to do it without lowering the feature set to the least common denominator and settling with that.

And the common denominator would probably cover 80-90% of uses. For the rest you'd still have to option to delve deeper and use some implementation-specific tools if necessary.

Re: Introducing PackageManagement in Windows 10

#93

Post by kristopolous »

stephengillie wrote: post #68
tomswartz07 wrote: post #26

Perhaps I missed it, but the article doesn't mention this in any way: Windows ABSOLUTELY needs a way to go from 'Fresh Install' to 'Fully upgraded' with minimal interaction. Linux can do this: run `apt-get dist-upgrade` in Ubuntu, and you get all of the most recent updates. However, in Windows, you install 3 updates, restart, install 5 updates, restart, install 110 updates, restart....

One of the core issues with breaking this pattern is that you're installing a new feature on this reboot, then installing all of its patches on the next reboot. So you install 186 updates on a fresh install. This includes .NET 4.5 (or 4.5.1 or 4.5.2), and requires a reboot. Now you're done right? You just installed 168 updates, how many updates can there be? On your next reboot, you get another 60 updates, of which 2…

that was decent work. Good job - really accurate.

Re: Introducing PackageManagement in Windows 10

#94

Post by Someone1234 »

e40 wrote: post #86
tomswartz07 wrote: post #26

Perhaps I missed it, but the article doesn't mention this in any way: Windows ABSOLUTELY needs a way to go from 'Fresh Install' to 'Fully upgraded' with minimal interaction. Linux can do this: run `apt-get dist-upgrade` in Ubuntu, and you get all of the most recent updates. However, in Windows, you install 3 updates, restart, install 5 updates, restart, install 110 updates, restart....

An addendum to this is that Windows needs to restart way too often compared to Linux. When I apply my daily yum updates for CentOS, only kernel updates, which are very infrequent, require a reboot. Every time I do Windows Updates, I need to reboot. This is highly annoying and IMO makes Windows Server YYYY completely unsuitable for servers.

Windows Server needs to restart at MOST once a month ("patch tuesday"). If I look at a 2012 Core server, it hasn't even restarted nearly that often in the past year. In fact 9 times in 12 months.

Plus I can schedule this restart at any hour, on any day, I wish. And do. For example I restart mine on Thursday morning at 1 am.

If that really makes Windows Server "unsuitable for servers" then your downtime requirements must be so high that any single server wouldn't be able to meet them (i.e. even with Linux you'd need two or more servers to provide that level of uptime).

Re: Introducing PackageManagement in Windows 10

#95

Post by Someone1234 »

tomswartz07 wrote: post #83
mhurron wrote: post #73

Earlier quoted context omitted.

The way around this is to update your deployment images from time to time. It's one reason I liked service packs, new service pack comes out, generate a new install image.

Right, and that takes care of the 'big ones', but you still have tons of other minor updates that are released every Patch Tuesday. I currently have Jenkins build an OS image every two weeks, just so our Deployment Server has an up to date image.

> released every Patch Tuesday.

It is the second Tuesday of the month, not every Tuesday. They've only broken that pattern a handful of times in the years that they have been doing it when an "emergency" patch was required.

Re: Introducing PackageManagement in Windows 10

#96

Post by bentcorner »

tomswartz07 wrote: post #81
stephengillie wrote: post #68

Earlier quoted context omitted.

One of the core issues with breaking this pattern is that you're installing a new feature on this reboot, then installing all of its patches on the next reboot. So you install 186 updates on a fresh install. This includes .NET 4.5 (or 4.5.1 or 4.5.2), and requires a reboot. Now you're done right? You just installed 168 updates, how many updates can there be? On your next reboot, you get another 60 updates, of which 2…

Yep, this is exactly what I'm talking about. I don't see why they cant 'look ahead' to say; Oh- this update X depends on update Y, but it's going to be installed, so we could just add it in the queue anyway.

Or rather, slipstream future updates to current downloads. E.g., if you're installing component X that has patches A, B, C, then perhaps you should get customers to download component X that is already in a patched state.

Re: Introducing PackageManagement in Windows 10

#97

Post by Someone1234 »

wtallis wrote: post #74
skrebbel wrote: post #66

Earlier quoted context omitted.

So?

If you want to do advanced stuff in your scripts, you've never been limited on unix systems to just sh or bash, but on Windows you still don't have a good shell for interactive use.

PowerShell ISE is pretty nice. I use it as my main shell.

Re: Introducing PackageManagement in Windows 10

#98

Post by akulbe »

Someone1234 wrote: post #94
e40 wrote: post #86

Earlier quoted context omitted.

An addendum to this is that Windows needs to restart way too often compared to Linux. When I apply my daily yum updates for CentOS, only kernel updates, which are very infrequent, require a reboot. Every time I do Windows Updates, I need to reboot. This is highly annoying and IMO makes Windows Server YYYY completely unsuitable for servers.

Windows Server needs to restart at MOST once a month ("patch tuesday"). If I look at a 2012 Core server, it hasn't even restarted nearly that often in the past year. In fact 9 times in 12 months. Plus I can schedule this restart at any hour, on any day, I wish. And do. For example I restart mine on Thursday morning at 1 am. If that really makes Windows Server "unsuitable for servers" then your downtime requirements m…

Once a month is way too often. Even if your downtime requirements are "so high", once a month is ridiculous.

For the sake of this example, let's assume you have customers that depend on your server being up, for the product/service they're paying you for.

Tell the customers that you plan on rebooting once a month, and see how they feel about it.

Re: Introducing PackageManagement in Windows 10

#99

Post by Someone1234 »

dragontamer wrote: post #37
WorldWideWayne wrote: post #33

Earlier quoted context omitted.

Yeah, one command - on every machine... Meanwhile on Linux, I don't need to do any special configuration to run scripts.

> on every machine... Or through one group policy pushed to every machine.

Plus, unlike what most people envision on here, Microsoft intends companies to push AllSigned or RemoteSigned, rather than Unrestricted.

So the company can push their CA and new PS policy in a single GPO, and then all internal PS scripts are signed using an internal CA generated code signing certificate.

This sounds complex but it is actually as simple as running Set-AuthenticodeSignature on each script using the code signing certificate.

Re: Introducing PackageManagement in Windows 10

#100

Post by eliaspro »

igravious wrote: post #6

I recently blogged about the Linux world needing something like this. http://leto.electropoiesis.org/propaganda/plugins-and-packag... I hate having to individually update my Wordpress install, my Rubies, my system packages, my IDE (be it Eclipse or Android Studio), a separate TeXLive install from the OS packages, even Vim now has its own package management with Pathogen... There must be some way to _unify_ this proli…

There's no need to unify the installation of those domain-specific package managers - those packages just need to provide proper machine-readable metadata to make it possible to build distribution packages out of them so there's no need to create another 10 package-datasilos outside of the system's package-manager's control.

The very idea of placing dependencies in a local location (or even worse in a global location but not controlled by the system package-manager) is so rotten from the core - it simply deserves to die.

What was once supposed to be a tool for developers to have easy access to dependencies has now crept into the area of operation and deploying uncontrollable stuff (Docker containers, 3rd party package managers, statically linked applications, manually built packages, …) into production systems has become the norm.

Post reply on HN