ralish

Uh, paying for DNS isn't uncommon? Examples off the top of my head:

- Akamai DNS

- AWS Route 53

- Azure DNS

- Cloudflare (excluding personal/hobbyist plan)

- Google Cloud DNS

And many, many others. And I note the site you posted this comment on is using Route 53, so probably paid as I doubt their query volume would be in the free tier.

Paying for DNS for personal/hobby stuff is probably pretty uncommon, because like you say, most domain registrars will offer it for free. But commercial websites often will, particularly larger ones with serious traffic.

I'm a bit rusty on this but from memory the overhead is by and large specific to the Win32 environment. Creating a "raw" process is cheap and fast (as you'd reasonably expect), but there's a lot of additional initialisation that needs to occur for a "fully-fledged" Win32 process before it can start executing.

Beyond the raw Process and Thread kernel objects, which are represented by EPROCESS + KPROCESS and ETHREAD + KTHREAD structures in kernel address space, a Win32 process also needs to have:

- A PEB (Process Environment Block) structure in its user address space

- An associated CSR_PROCESS structure maintained by Csrss (Win32 subsystem user-mode)

- An associated W32PROCESS structure for Win32k (Win32 subsystem kernel-mode)

I'm pretty sure these days the W32PROCESS structure only gets created on-demand with the first creation of a GDI or USER object, so presumably CLI apps don't have to pay that price. But either way, those latter three structures are non-trivial. They are complicated structures and I assume involve a context switch (or several) at least for the Csrss component. At least some steps in the process also involve manipulating global data structures which block other process creation/destruction (Csrss steps only?).

I expect all this Win32 specific stuff largely doesn't apply to e.g. the Linux subsystem, and so creating processes should be much faster. The key takeaway is its all the Win32 stuff that contributes the bulk of the overhead, not the fundamental process or thread primitives themselves.

EDIT: If you want to learn more, Mark Russinovich's Windows Internals has a whole chapter on process creation which I'm sure explains all this.

If they're integrated into the OS they have to be supported at the same level as the rest of the OS, which entails the same rigorous processes w.r.t. updates, bug fixes, etc...

By keeping them out-of-band, that support requirement doesn't apply, allowing the tools to be much more aggressively updated and released without the same degree of oversight. There's a reason they're licensed separately and effectively with no support or warranty. Doing so enables their rapid development without/less-of the usual bureaucracy.

Hence the Delay option.

Uh, that may not be the best example. Are you aware of a reliable way to retrieve the OS version across all POSIX OSs? Because if you are, I would love to hear it.

Sure, but the degree of usage of cmd makes Silverlight's usage look like a hobby project. It's used everywhere, including all over Microsoft's own software. It'd easily be the single biggest backwards incompatible change ever made by Microsoft and would affect software going back to the 1980s. The engineering effort involved to migrate anything that is using cmd is mind boggling, to the extent of being completely infeasible. It's a safe bet that for as long as Windows is around, cmd is going to stay with it.

Agree that the phrasing could have been a lot clearer, but really, Microsoft removing cmd just doesn't pass even a basic sanity check. I remember seeing the original news articles and just ignoring them as obviously rubbish. It's pretty sad to see so many tech news sites & aggregators just pick-up and run with stories like that which anyone at all knowledgeable about the subject area would immediately know is hyperbole.

It's certainly a lean web site. Or rather, the 503 is lean.

It appears to be a support library for dfp.exe, which is the "Disk Footprint Tool". I never knew it existed until now, but it seems to be a potentially quite handy utility with a purpose similar to tools like WinDirStat (but CLI only?).

So to answer your question, no, it's not part of the telemetry infrastructure. And I'll add that calling that infrastructure "spyware" is a simplistic analysis of what's a complex issue. I say that as someone who goes to great pains to turn off as much telemetry as I can across almost all applications I use.

It's not inherently bad, but choice for choice's sake is generally not a good thing for security software in my view.

Saying you support more features in non-security software might be a great thing but saying you support more ciphers, encryption algorithms, etc... than the competition just means a higher probability you're supporting weak/broken security algorithms and/or that the implementations are not well audited.

That, and the overwhelming majority of users are going to have no idea what the actual difference is between all the options nor are going to take the time to investigate what exactly is the difference between RIPEMD-320 & SHA-512. Nor should they have to for that matter.

The goal here is to implement high quality security software. The more features you support, the more code is in your product, and the harder it is to ensure that your code is in fact delivering the security you're aiming for.

What options are superior to XTS? As I understand it XTS does have some weaknesses, but is still the superior option versus LRW & CBC w/ secret IVs. I'm not aware of any other well supported block cipher modes other than those major three?

What are you talking about? Cygwin provides packages for bash, dash, fish, tcsh, zsh, and others. It's not a crutch, these are the exact same shells you run on Unix(-like) systems. The source is the same, albeit with some Cygwin specific patches, but that's no different than any other Unix-like distribution that applies patches to upstream packages (e.g. Debian, FreeBSD, Gentoo, etc...).

Your NiH assertion doesn't even remotely make sense. PowerShell is fundamentally different from traditional Unix shells and has many interesting, unique & innovative features. Not liking them or agreeing with the philosophy is entirely valid, but suggesting they've just refused to use an existing shell because of NiH isn't born out by the facts.

Honestly, I'd suggest trying to adapt an existing Unix style shell to Windows as the "official" shell would be an inherently bad idea at worst and extremely difficult at best. Apart from the numerous issues that traditional shells have which PowerShell seeks to address (reliance on string parsing, lack of consistency in commands/parameterss, etc...), traditional Unix shells are very much built around a Unix operating system philosophy, especially wrt. exposing operating system internals, devices, etc... via the file system. That's a great thing, but it's not so much applicable to Windows.

You'd either need to radically re-design large chunks of the system to conform to the Unix philosophy of exposing much of the system via the file system, which let's face it, is unlikely to happen, much less any time soon, or augment the shell with a lot of extra support for Windows specific functionality (e.g. the Registry, WMI, etc...). Things as simple as ACLs on Unix won't even map nicely. Better to have a shell that works well for Windows and fits its administrative model than trying to shoe-horn in a shell designed with a completely different administrative philosophy in mind.

You mention OS X, and yes, they did get it to work. As other commenters have mentioned though, OS X is UNIX. As in, UNIX(R). The userland API exposed by the kernel is based off BSD, as are large chunks of the operating system (although, Apple seems to be replacing them one by one). It's pretty easy to use a nix shell when your operating system is largely based on Unix (at least, from the perspective of userland applications).