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).
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).
IE7 shipped with Vista. I've seen a few organisations that started deploying Vista and updated their XP systems to IE7 so all their workstations are running the same IE version.
Admittedly, there aren't many of these companies given most gave Vista a miss in favour of 7 or something else entirely, but they do exist, and it is a plausible reason that IE7 is still around for some.
I think you've possibly misinterpreted the argument the author is making. My interpretation wasn't that he was being critical of the FBI for shutting it down; of course they had to shut it down. Rather, the criticism is of the laws and policies that are in place which dictate that the FBI had to shut it down in the first place.
As the article notes, law enforcement has been given a "hopeless task", where if you subscribe to the view that Silk Road actually made buying and selling drugs safer (as I do), shutting it down has made the whole business less safe at direct risks to citizens of many countries. As you note, the FBI had to do this, but it's a huge indictment of our drug policy that this is the action they are compelled to take given the result.
I'm sorry, but that's absolute rubbish. I rarely post on HN, but I feel compelled to do so here.
People rarely live in a vacuum, they engage with society, and those interactions have tangible results. I feel this is obvious, but it seems lost on people. When a person is systematically bullied, that negative interaction with society will inevitably have an impact, and if severe enough, suicide is a potential result. Aaron had the weight of a state on his shoulders, and while I'm glad to say I've never experienced that the prospects of it terrify me. As someone with a history of depression, I can quite confidently state, I'm unsure I'd survive through the experience, and can foresee it simply becoming too much.
To state that no one has responsibility for his death is to excuse the gross abuses of those who's interactions with Aaron led to it. You are giving a pass to disgraceful prosecution tactics including intimidation and overreach. You are giving a pass to institutions that abandoned morality by siding with an abusive prosecution instead of standing up for a member of their community. Most egregiously, you are encouraging a broad view that only the victim is at fault for their choice. There's so much wrong with this view it's hard to know where to start, but for one, it suggests they're in the position to even logically and rationally evaluate the choice. If you're depressed to the point of suicide, it's fairly safe to assume, you aren't thinking logically or rationally. How can you then be held at fault for the resultant choice?
Suicide is horrible, and I've known some who've taken that path. But blaming those who commit such an act is the easy way out. To reduce the instances of people taking their own lives, you need to understand why. This means fully comprehending the circumstances that led to their choice, and this means holding those to account that contributed to it.
- 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.