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

181–190 of 221 posts

Re: Introducing PackageManagement in Windows 10

#181

Post by simoncion »

gnoway wrote: post #144
SwellJoe wrote: post #122

I was going to say, "Finally! They've gotten it right after all these years of sucking so hard as to be unusable on servers." But, I did some digging into the github for OneGet ( https://github.com/OneGet/oneget )... And, they haven't gotten it right. Windows package management still sucks so hard as to make the OS unusable on servers (and annoying as hell on the desktop). This is seemingly a simple-minded downloader…

As long as there is no single prevalent native package format for Windows, packaging is going to suck on Windows. That's why this tool exists, but I don't think attacking a big mess with more complexity is the right approach. I hope I'm wrong, but I think this will end up 'successful' only in the way NuGet is 'successful' - there's not really any competition. What I'd hoped for is that MS would commit to extending MS…

Wait. Are you saying that MSFT is going to walk away from the everything-and-the-kitchen-sink installer format that is MSI? This is actually (seriously!) a bit surprising to me!

Re: Introducing PackageManagement in Windows 10

#182

Post by useerup »

Aleman360 wrote: post #20
WorldWideWayne wrote: post #16

Please give us something that doesn't require PowerShell, since PowerShell never just works. Just look at the ridiculous bullshit that you have to deal with when you want to use Chocolatey (from the Chocolatey install guide): Note: You must have your execution policy set to unrestricted (or at least in bypass) for this to work (Set-ExecutionPolicy Unrestricted). There have been reports that RemoteSigned is enough for…

PowerShell is disabled by default for security reasons. It's one command to enable it.

> PowerShell is disabled by default for security reasons.

Small correction: PowerShell script files are disabled by default for security reasons.

PowerShell is available with all Windows versions since Vista SP1.

On the latest Windows versions, remote command (part of Remote Management) is enabled by default. I.e. you can connect (given proper credentials) to a Server 2012R2 through PowerShell remoting and execute commands.

Indeed, the new "Server Nano" will not have any way to log in locally at all. There is no shell (as in operating system shell), and no local editor (like notepad). Only the remote command interface. PowerShell will be extended to allow remote file editing - i.e. use a local editor for a file residing on the remote computer (been missing that for the longest time now)

Re: Introducing PackageManagement in Windows 10

#183

Post by useerup »

ddingus wrote: post #177
akandiah wrote: post #162

Earlier quoted context omitted.

A lot of the time, restarts are required to remove old versions of files that are still in use. AFAIK, there is no way to remove files that are 'in-use' (and not locked) without having to make an entry in the registry to schedule a deletion on the next reboot.

I always wondered about that. Shouldn't a real OS and filesystem be capable of removing something in use? IRIX always could. So can Linux a whole lot of the time, if not all the time, as can BSD and Mac OS. Here's something: Once I upgraded a pile of IRIX boxes to a new version of some CAD software. A few of them had the older version running... Didn't matter! The files got cached, and those versions continued runnin…

> Shouldn't a real OS and filesystem be capable of removing something in use?

It's a choice. Windows specifically uses DLLs as non-dirty swap, i.e. if the memory manager want's to free up pages it may free memory pages used for mapping a least recently used DLL because it will not require it to write any "dirty" memory. A DLL page can never be dirty. Windows knows that it really easy to read in the image again (from the DLL) - so it can just kill the page and reuse it immediately. But then it has to know that it can get the exact same memory page back from the DLL. If the DLL has been deleted or changed that would lead to some strange errors.

Re: Introducing PackageManagement in Windows 10

#184

Post by rando289 »

PeterLindt14 wrote: post #167
SwellJoe wrote: post #122

I was going to say, "Finally! They've gotten it right after all these years of sucking so hard as to be unusable on servers." But, I did some digging into the github for OneGet ( https://github.com/OneGet/oneget )... And, they haven't gotten it right. Windows package management still sucks so hard as to make the OS unusable on servers (and annoying as hell on the desktop). This is seemingly a simple-minded downloader…

Haters gonna hate. Where comes all your frustrations from? I've never had any issues with dependencies on Windows. If some C++ redestributables are missing, they are commonly installed by the installer. .NET Framework the same. For development NuGet.

And when a library has a security update, the software which contains it does not get updated, because it's repackaged by 10,000 different software companies that don't care or don't have the resources, and they sit side by side, and disk usage is way bigger than linux. This is partly fixed by the fact that installing software is such a pita and hard to automate that you don't install much 3rd party software on windows.

Re: Introducing PackageManagement in Windows 10

#185

Post by useerup »

thrownaway122 wrote: post #174
mdlowman wrote: post #155

Earlier quoted context omitted.

DLL hell certainly used to be a big issue in Windows. But I disagree that it remains a major factor; Windows apps are increasingly bundled and Windows system functions that used to be the cause of these issues, like DirectX, are packaged as redistributables that allow side-by-side installs.

How do they handle security updates? Does every app have to update all its own libraries in an e.g. heartbleed scenario?

There's the WinSxS and the GAC (Global Assembly Cache). In SxS actually means side-by-side. Both WinSxS and the GAC supports multiple versions of the same libraries, and the program manifests set up policies for which library versions they require/accept.

An application may for instance say that it accepts any newer "minor" version.

For security patching you can replace a library with a new "build". So if an application uses libraries placed in WinSxS or the GAC it will pick up any centrally patched libraries without the risk of jumping to a too new version with breaking changes. The new version can exist alongside older versions and they can all be patched - for security reasons or otherwise.

A vendor can also distribute libraries alongside the application - in the application library itself. In that case the responsibility for patching is placed squarely on the vendor of that application.

Re: Introducing PackageManagement in Windows 10

#187

Post by alkonaut »

thrownaway122 wrote: post #174
mdlowman wrote: post #155

Earlier quoted context omitted.

DLL hell certainly used to be a big issue in Windows. But I disagree that it remains a major factor; Windows apps are increasingly bundled and Windows system functions that used to be the cause of these issues, like DirectX, are packaged as redistributables that allow side-by-side installs.

How do they handle security updates? Does every app have to update all its own libraries in an e.g. heartbleed scenario?

Not sure who "they" is here, ut in windows: pretty much, yes. You can't have it both ways. So you either have a centralized/shared lib environment where you may run into conflicts but you get centralized patching, or you have self contained applications where you need to patch each one but you never have lib dependency/upgrade issues. Simple as that.

Re: Introducing PackageManagement in Windows 10

#188

Post by Latty »

derefr wrote: post #161
drzaiusapelord wrote: post #50

Earlier quoted context omitted.

>restart This isn't going to happen. MS is tied deeply into restarting due to how it loads libraries and other issues. Unless they write a new OS from scratch and give up on legacy compatibility, well, don't hold your breath.

Even in Linux you've got to restart once, if you update the kernel or somesuch. The problem with Windows is the restarts before the final one, where you need to finish upgrading to version N+1 before the updates taking you to N+2 will even download. If the updater software could just plan out a patch-graph ("once I do X, then Y will be available, so I'll do Y, and that means Z will be available"), then apply all the…

Actually the 4.0 release has added support for no-reboot kernel patching, IIRC.

Re: Introducing PackageManagement in Windows 10

#189

Post by tne »

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…

This is the approach taken by LY-Linux ("patch leap year"), although better implemented IMO. In fact, I typically only have to restart my servers once every 4 years (at most).

Look it up, it's awesome. (Please don't.)

Re: Introducing PackageManagement in Windows 10

#190

Post by useerup »

maratc wrote: post #35
maccard wrote: post #27

Earlier quoted context omitted.

You mean like PowerShell?

No, the one with history going back more than an hour, and tab completions on anything except files in `pwd`.

> No, the one with history going back more than an hour

When did you last try PowerShell?

In version 1.0 the history size was 64 by default - but could be changed.

In PowerShell v3 that's increased to 4096 by default. If you can overflow that in an hour you are a seriously impressive typist! That more than one command line per second - sustained.

If you manage to break that, you can assign any value up to 32767 - yes that's 9 different commands per second.

PowerShell can discard duplicates, so if you manage to break 4096 different commands in the run of one day you are doing something wrong.

Like not using snippets (http://blogs.msdn.com/b/powershell/archive/2012/06/27/snippe...).

Oh - i forget - bash don't do snippets.

> and tab completions on anything except files in `pwd`.

Seriously, have you tried PowerShell - like ever?

PowerShell's tab completion blows anything bash out of the water: o PowerShell tab completions are based on command metadata - not on external "completion definitions". The result is that tab completion works for all cmdlets - not just for those that has a "completion file". o PowerShell will complete on anything: Command names, parameter names (options), parameter values - even dynamic values. Try this on PowerShell "ps " - and you'll be allowed to complete based on the names of running processes. o PowerShell tab completion also works for parameters of user defined functions - and even for parameters of script files. If you declare a script to take parameters, PowerShell will pick it up and allow tab completion on the parameter names and allowed values.

Post reply on HN