Live data from Hacker News

Introducing PackageManagement in Windows 10

blogs.technet.com

211–220 of 221 posts

Re: Introducing PackageManagement in Windows 10

#211
post #209

Earlier quoted context omitted.

http://blogs.technet.com/b/windowsserver/archive/2015/04/08/... "To achieve these benefits, we removed the GUI stack, 32 bit support (WOW64), MSI and a number of default Server Core components."

You probably have far more expertise in this area, but I don't see this as solid evidence that MSFT is walking away from MSI. I mean, they also removed WOW64 and the GUI. It would be absurd to think that MSFT would ever drop support for the GUI in every version of Windows Server. :)

I don't, my earlier thoughts should indicate that I have less (or none). Thinking about this more it's more likely that Nano Server won't have packages at all: the container will be the package. You'll build the image and it will have whatever it has. If you need to add/remove 'packages' you will build a new image. So, no need for package management inside the container -> no need for MSI.

Re: Introducing PackageManagement in Windows 10

#212

Earlier quoted context omitted.

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…

Thanks.

Re: Introducing PackageManagement in Windows 10

#213

Earlier quoted context omitted.

> PowerShell and its object pipeline are focused on cmdlets which are not arbitrary programs, they are .NET classes, and PowerShell objects are .NET objects. Both correct and horribly wrong. PowerShell is indeed focused on cmdlets (and functions) and it's pipeline concept is focused on objects. It is also correct that cmdlets are not arbitrary programs. However, cmdlets are not .NET classes. It is true that you can i…

> your assertion that cmdlets are .NET classes is both factually wrong They are instances of .NET classes that derive from `Cmdlet` and `PSCmdlet` and run in the PowerShell runtime. As stated plain as day in the Microsoft cmdlet documentation: "Cmdlets are instances of .NET Framework classes; they are not stand-alone executables." Your entire comment is an attempt to obfuscate the nature of PowerShell cmdlets, which…

You look at the developer documentation for developing PowerShell cmdlets using C#, and go "look! it says you create cmdlets using C#!".

Well, here is another way to create cmdlets: https://msdn.microsoft.com/en-us/library/jj542520(v=vs.85).a...

Yes, you specify cmdlets using XML. You can point to static methods, remote CIM objects.

It may very well use .NET classes underneath. The implementation details are immaterial to how PowerShell works.

PowerShell is certainly built using .NET - and require that commands are built (or at least execute) under .NET.

However, PowerShell works with objects. An object is a collection of properties and methods that work on the object. Every command in PowerShell must be able to understand the objects, hence a common binary object format must be specified. PowerShell choses .NET objects as it's lingua franca - the PowerShell type system, although it extends it.

PowerShell specification says that commands that specifies parameters must do so with types from that type system, and if they support pipelines they must consume objects from the type system and produce objects from the type system. It is a protocol

This is very much like how sh shells specifies that commands must support arguments as an array of strings and can optionally consume byte streams from stdin and produce byte streams to stdout. It's a protocol

Does PowerShell use the same protocol as sh shells? No. Hence, the commands are different.

You do not like that they are different? fine. Don't use it.

Your pipeline illustration should have been:

PowerShell's cmdlet / object pipeline: (PowerShell runtime | adapter(arbitraty old-school stdin/stdout) | ironpython runtime | any runtime that adheres to type system)

Unix Pipeline: (Python runtime) | (arbitrary executable) | (PowerShell runtime) | (Ruby runtime)

Yes, PowerShell raises the bar for commands: They must meet some other criteria than string args and stdin/stdout. But just like sh shells and stdin/stdout executables, PowerShell and cmdlets build an ecosystem. It may hurt to realize that the world one knows is just one possible world, and that there may be others out there where some things may be easier and other harder.

To me, it is an opportunity to learn. Nothing quite like being shaken up a little.

Re: Introducing PackageManagement in Windows 10

#214
post #195

Earlier quoted context omitted.

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

This is no different from the situation in Linux, BSD etc, where executables and libraries are simply mapped into the process with mmap() - they're backed by the files and the system is free to discard those clean memory pages as it sees fit. When you install(1) a new version of a file, the old one is deleted and the new one written in its place. The file handle in existing processes continues to point to the origina…

Thanks for clarifying. That boils down to linux perfectly hiding this problem from the user, while windows painfully makes the user restart every time a file is in-use and needs to be removed.

Re: Introducing PackageManagement in Windows 10

#215
post #201
post #104

Earlier quoted context omitted.

that's basically what conemu brings

Disclaimer ConEmu is not a shell, so it does not provide "shell features" like tab-completion, command history and others. [1] [1] https://code.google.com/p/conemu-maximus5/

Fair point, my mistake: my ConEmu does have history and copletion but it has been so long ago I installed it I didn't remember this is through clink

https://code.google.com/p/conemu-maximus5/wiki/ConEmu_Clink

Re: Introducing PackageManagement in Windows 10

#216

Earlier quoted context omitted.

You can update the software without pulling it down. In order to use the update you need to restart, but there's a large difference between restarting a service and restarting an OS. It isn't really analogous.

It takes 10 seconds to restart Windows these days, so it's almost analagous.

That is BS. When you install updates it restarts to install them. The time is proportional to the number of updates.

Re: Introducing PackageManagement in Windows 10

#217
post #207

Earlier quoted context omitted.

You can see it when you do a video search for: Windows fast boot. Here are a couple: https://www.youtube.com/watch?v=p_vUZR2RtRs https://www.youtube.com/watch?v=xkKoggifsE4 (And you don't need to log in for your background services to start.)

Neither of those support your original claim. The author is focused on one specific feature, which is nice but excludes the entire shutdown process and booting up until the Windows logo appears. Anyone who's run a server knows that just the BIOS initialization is often much longer than 10 seconds. And, of course, many services take a noticeable amount of time to startup so time-to-available is longer than time-to-log…

I understand all of that and I agree with you.

However, if people are going to make irrelevant points about "not having downtime with Linux" then I am going to fuck with them.

Re: Introducing PackageManagement in Windows 10

#218
post #82

Earlier quoted context omitted.

It's an ssh client. It is robust, easy to install and it works well. How much energy do you expect me to waste evaluating and choosing new ones when the one I have works just fine the way it is? I have better things to be doing.

This is the poison in the open source world. If you have something that works "well enough" but never evolves, it holds everyone back. The barrier to entry is fairly high for an application like this, so I'm not saying this is an easy thing to fix, but it's worth fixing. Linux in particular is filled with "well enough" solutions that should be striving to be better. Although there's misfires when controversial things…

But whats wrong with PuTTY?, is it missing features?, I mean. like it has full SSH support, its easy to use, and has a non-quirky terminal emulator.. I guess it could have more terminal types, but there are closed source options for that, like Reflections.

Re: Introducing PackageManagement in Windows 10

#219

Earlier quoted context omitted.

> your assertion that cmdlets are .NET classes is both factually wrong They are instances of .NET classes that derive from `Cmdlet` and `PSCmdlet` and run in the PowerShell runtime. As stated plain as day in the Microsoft cmdlet documentation: "Cmdlets are instances of .NET Framework classes; they are not stand-alone executables." Your entire comment is an attempt to obfuscate the nature of PowerShell cmdlets, which…

You look at the developer documentation for developing PowerShell cmdlets using C#, and go "look! it says you create cmdlets using C#!". Well, here is another way to create cmdlets: https://msdn.microsoft.com/en-us/library/jj542520(v=vs.85).a... Yes, you specify cmdlets using XML. You can point to static methods, remote CIM objects. It may very well use .NET classes underneath. The implementation details are immateri…

What still seems to be getting missed is that despite some superficial similarities, Unix pipelines and PowerShell pipelines serve different purposes, operate on different levels, function totally differently, and are not interchangeable within the system.

Unix pipelines are an operating system feature that coordinates data streams between processes. PowerShell's object pipeline is function chaining feature of PowerShell, a runtime that runs on an operating system as a process, the kind of process whose communication with other processes is coordinated on Unix systems using Unix pipelines.

Python, PowerShell, and Ruby object handling and function/method chaining are not a features at the operating system level, they are features within the Python, PowerShell, and Ruby runtimes and processes. Unix pipelines are a feature at the operating system level that coordinate communication between these kinds of processes.

Unix pipelines are not a feature of Unix shells, they are an operating system feature for which shells provide an interface. PowerShell's object pipelines are features of PowerShell and its runtime, not the host operating system.

This is not a minor distinction. A feature for working with objects and chained functions within particular language or framework's runtime is not the same thing as a feature for coordinating process communication in an operating system.

Re: Introducing PackageManagement in Windows 10

#220
post #211

Earlier quoted context omitted.

You probably have far more expertise in this area, but I don't see this as solid evidence that MSFT is walking away from MSI. I mean, they also removed WOW64 and the GUI. It would be absurd to think that MSFT would ever drop support for the GUI in every version of Windows Server. :)

I don't, my earlier thoughts should indicate that I have less (or none). Thinking about this more it's more likely that Nano Server won't have packages at all: the container will be the package. You'll build the image and it will have whatever it has. If you need to add/remove 'packages' you will build a new image. So, no need for package management inside the container -> no need for MSI.

That's actually a really good thought about the reason for MSI removal in Nano Server!

(And, TBH, my only experience with MSI was briefly working with a vaguely recent version of InstallShield several years ago. The fact that you can talk about the pain of MSI authoring probably indicates that you understand more about the topic than I do. I just clicked some buttons in the InstallShield UI, and skimmed some of the MSI developer docs. :) )

Post reply on HN