This appears to be the correct answer. Backed up here:
1,312 karma · joined January 4, 2013
Who is going to buy this? Who is it for?
Anyway, if there's a product out there which doesn't provide this capability, no amount of bill passage is going to make that product work like some congressperson wants.
Do I remember the name of the signing cmdlet(s)? Nope! Is this really better than just using alias, or changing the PATH? Probably not.
Another reason is vendor support. For example, VMware publishes a set of PS cmdlets as 'PowerCLI' for doing stuff in vSphere, but if you want to do something outside PS you're going to have to script/code against an SDK. I suspect there are other vendors doing the same thing. That may be a PS benefit. I usually end up writing a script instead although I found e.g. bulk movement of VMs from one set of datastores to another easier in PS.
The final thing I can think of is that there are a few situations where maybe you want things to stay in-process, and you get that w/ PS whereas you wouldn't with bash. An example I have is a script that facilitates remote deployment of an MSI with impersonation of a user on the remote machine. This is pretty straightforward with a WMIObject in PS, but not in cygwin bash since Windows doesn't really have sudo or su -c (runas only works interactively) and wmic doesn't offer any impersonation capability.
None of the above are really compelling for me, I end up spending 99+% of my time in bash/tmux/mintty.
Quick searches reveal this is a popular question, spot checks of the answers agree that it's not illegal and quite common.
The rest of your explanation is just specious, as pointed out by other people, and also reflects poorly on your company.
I guess my point re: Chocolatey is that they depended on a bad upstream tool that has moved in a different direction from what Chocolatey probably needs. So Chocolatey is either stuck on an old codebase - MS says they are going to maintain v2, but who thinks that is going to last? - or they are forking and maintaining themselves, which also seems unlikely as they risk giving up compatibility with all the NuGet repo software they also kind of depend on.
Or, if you insist on writing 'unmanaged code,' you are probably finding similar capabilities in native libraries distributed with Windows; it's DirectX's natural environment. Otherwise, you're responsible for doing as you suggest: downloading/compiling the various libraries and stashing them in a nominated area for use by your build toolchain.
Also there's always msys2/mingw64, which does have a package manager (pacman I think?) and you woudl then distribute the necessary runtimes with your program.
Think carefully before using Chocolatey. It is not, never has been, and never will be the default package system for Windows. IMO the writing is on the wall as MS ships OneGet with Windows 10; while I think I read something about the projects working together, or OneGet supporting Chocolatey repositories or something, I don't believe OneGet's 'native format' will be Chocolatey packages.
On top of this, Chocolatey is based on v2 of NuGet, which is a) terrible and b) superseded by v3, which is the go-forward version that has a different package format and capabilities.
I am not sure why anyone would seriously consider using Chocolatey for a new project today.
Of course in this case the person is a corporation; if this defense works I wonder if there will be calls for renewed scrutiny of corporate personhood. This may have been discussed in the article, but I was unable to read very far because I have an ad blocker turned on.
Several years before that purchase, Stephen Elop (an MS executive) became CEO of Nokia. Within 6 months of his hire, Nokia signed an agreement with MS to sell Windows Phone devices; the classic Symbian OS and the Linux-based Meego - both of which had shipping hardware - were canceled in favor of exclusive focus on Windows Phone. Within the next few years, Nokia laid off over 20k people, their stock dropped by about 85%, and they even sold and then leased back their HQ in Finland. They were a lot less successful by that point, and a lot less expensive to purchase. Which Microsoft did.
There was some amount of controversy associated with the above.
In this case, the intended answer/conclusion/implication is "yes, this is."
Doesn't really excuse Adobe.
[0] https://blogs.windows.com/windowsexperience/2016/01/15/windo...
You're correct in that trim is less necessary if a drive has good garbage collection. I don't know anything about the implementation of either, but I would expect trim to be easier, cheaper and better than GC. It seems like GC would require work to discover/remember things provided as input w/ trim. I've assumed that GC was only implemented by vendors in their controllers because trim wasn't available in the popular OSs yet, and/or because their controllers were already doing most of the work required by GC anyway so it was cheap to implement.
Finally, you can't equate SSDs with the SD or eMMC used in some of the phones/tablets. Yes it's all flash, but an SSD is typically multi-channel with many flash modules, a DRAM cache and a much more sophisticated controller implementing a standard storage interface (AHCI/SATA or SAS or NVMe). eMMC and SD are much simpler, cheaper and slower.
It's been a long day.