Live data from Hacker News

Introducing PackageManagement in Windows 10

blogs.technet.com

111–120 of 221 posts

Re: Introducing PackageManagement in Windows 10

#111

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…

that was decent work. Good job - really accurate.

I'm going thru the process as we speak. :)

Re: Introducing PackageManagement in Windows 10

#112
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…

Windows Server needs to restart at MOST once a month ("patch tuesday").

BUT if Windows patches came out as often as CentOS patches do, I'd been rebooting every other day.

Re: Introducing PackageManagement in Windows 10

#113
post #92

Earlier quoted context omitted.

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…

I just think it's a mistake to believe that the solution to the proliferation of package managers is to write a package manager manager.

Re: Introducing PackageManagement in Windows 10

#114

Oh, wow. Please, can I get a decent command line now?

you can get conemu

Tried it, and it looks nice ... however crashes very often for me, and sometime becomes horribly slow (typing and seeing it displayed takes close to a second..)

Re: Introducing PackageManagement in Windows 10

#115
post #15

Earlier quoted context omitted.

>There must be some way to _unify_ this proliferation of software update mechanisms. https://gnu.org/s/guix https://nixos.org

Unify != replace. Guix/Nix don't integrate multiple package managers, it just is Another Package Manager.

Nix runs on any linux distro because all packages are stored in /nix, so it's not trampling all over your files in /usr, /bin, etc. It also runs on OS X (packages work, but are a bit less well tested, and the binary replacements are currently not as easily available as they should be). In the past it has been made to run on BSD and Windows through Cygwin, but these need a lot more work before being production ready.

It's also significantly more flexible than other package managers due to how it can handle multiple versions of the same package in an elegant way. This makes unifying diverse package sets an actual possibility. Apt, yum, etc are too limited to unify package sets in this way, an creating another layer above them in order to integrate them is hacky, ugly, and unlikely to work well.

Re: Introducing PackageManagement in Windows 10

#116

Earlier quoted context omitted.

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.

That's the kind of functionality I expect from Windows Deployment Services.

Re: Introducing PackageManagement in Windows 10

#117

Earlier quoted context omitted.

> PowerShell never just works. That statement is a bit much. I agree the default execution policy is annoying, but can you blame MS for being a little overzealous given their history? Some aspects of Powershell are actually pretty nice. Ever want to use a real hashmap in bash for example? Or easy JSON construction/manipulation without hacks like jq? PS has all that.

> Ever want to... That's because Bash is used to tie together separate programs that do the work. PowerShell, on the other hand, is a .NET shell and more equivalent to the shells in Python, Node, Ruby, the JVM, etc, all of which provide ways to work with JSON and many different data structures.

That's a false distinction. bash has a (primitive, idiosyncratic) language built-in. So does PS. They also are both designed to glue together independent programs via the pipe abstraction. The difference is that PS has much more modern language constructs and capabilities. The fact that it hooks into the .NET API as well is only a convenience.

Re: Introducing PackageManagement in Windows 10

#118
post #98

Earlier quoted context omitted.

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.

Popular (gaming) services have weekly downtimes to patch servers, and while users are annoyed, they seem to get over it and keep playing just fine.

Re: Introducing PackageManagement in Windows 10

#119
post #74

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.

How is it fair to give the example of the Python shell in Unix but not in Windows when it runs in both?

Re: Introducing PackageManagement in Windows 10

#120
post #91

Earlier quoted context omitted.

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 ...

WSUS just caches updates locally, so you can download once and have the WSUS server distribute copies to your forest.

It's a GPO that points your domains to the WSUS server. And I've only used Octopus to automate WU installs.

Post reply on HN