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.

Comments URL: https://news.ycombinator.com/item?id=19621799

Points: 257

# Comments: 178

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.

"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."

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.

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).

https://github.com/ralish/dotfiles

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.

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).

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.

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.

Which brings us back to the war on drugs...

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.

Could you perhaps elaborate as to what you would do to control a mentally ill child such as her own?

As of writing, the number of Tor routers is in the low thousands and of course only a minority of those are exit nodes. Technically savvy people like the HN readership (who also often have a strong online civil rights interest) make pretty good candidates for helping the network out via running a Tor relay!