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.
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.
Because it's well known by anyone interested in this area? There's been a barrage of "Windows 10 Telemetry/Privacy" related stories since its release. It's also publicly documented by Microsoft itself: https://technet.microsoft.com/en-au/itpro/windows/manage/con...
"Performance and reliability data, such as which programs are launched on a device, how long they run, how quickly they respond to input, how many problems are experienced with an app or device, and how quickly information is sent or received over a network connection."
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 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.
I've found Stow to be outstanding. When I initially started actually maintaining my dotfiles properly I looked at what others were doing based on public repositories and most at the time were either not using any sort of management tool (manual symlinking as needed) or using something written in a interpreted language that couldn't be assumed to be on a diverse range of Unix-like systems in default installations (e.g. Ruby, Python, Node.js, etc...).
The problem was I wanted something I could easily install on effectively any system, including live servers, without needing to install dependencies or otherwise change the underlying global system state. Stow manages to solve this beautifully as pretty much all Unix-like systems do have a Perl interpreter and Stow has no unusual dependencies beyond the core runtime. That, and it can be included in your dotfiles collection itself, so you can literally "stow stow" to "bootstrap" itself and then carry along!
If anyone's interested you can find my dotfiles below which may be nice as reference material if you're wanting to "stow-ify" your dotfiles. I've also written some Bash scripts to automatically stow the available components on a given system (dot-manage) and easily fetch updates from an upstream repository, re-run component detection and update Vim bundles via Vundle (dot-update). There's also a metadata-esque system which augments detection of which components are available for where simply checking if a binary named after the relevant folder exists on the system is insufficient (e.g. for libraries like readline).
- 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.