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.

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

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

https://github.com/ralish/dotfiles

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.

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

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.

Considering she explains in detail how she has had to take him to hospital multiple times with the assistance of police to restrain him, and further admits that pressing charges against him is perhaps the only last remaining option (which she indicates she is understandably reluctant to do), I'm having a hard time seeing what she isn't doing?

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

Looking at the current list, the CCC contributes a substantial slab of resources to the overall network. It's a pretty suboptimal situation that the network performance could be impacted/compromised by one organisation (potentially) pulling its support for whatever reason.

Firstly, we'd need a massive expansion of the Tor network. While Tor might be quite well known among the more technically inclined, the network itself is of course largely composed of volunteer systems and is quite small: http://torstatus.blutmagie.de/

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!

Most of the responses to the question seem to be "sort of" correct but missing important parts of the overall picture. Further, a complete answer to the question is going to be subject to the operating system the given application is running under as the specifics are going to be heavily dependant on OS implementation.

I can't speak for Unix systems, but on the Windows side, it's complicated and messy:

PAE (Physical Address Extensions)

Client editions of Windows do not support PAE while server editions do. If you want to physically address more than 4GB of RAM you need PAE. Realistically, you're unlikely to be able to address even 4GB under non-PAE x86 due to reserved memory ranges from hardware taking a chunk.

Funfact 1: As for why PAE isn't supported on client editions, this isn't a licensing problem (you can buy x64 editions for the same price that have massively increased RAM limits), but rather, Microsoft playing it safe with driver compatibility. Apparently, during testing a non-trivial number of drivers were found that made assumptions that don't hold under PAE and thus broke horribly. Things like using the high bit of a 32-bit pointer for data storage. Rather than risk a tsunami of bluescreens caused by poorly written drivers (which people would blame MS for out of naivety) the decision was made to simply not support PAE on client editions. Server editions do as there's the reasonable expectation that servers should be running higher quality drivers.

Funfact 2: Technically, PAE is supported on client editions, as it's required for hardware DEP support, so it's more a hard limit on addressable physical memory than it is a lack of support for PAE itself.

AWE (Address Windowing Extensions)

This is a Windows-specific capability (unlike PAE, which is a hardware capability provided by modern CPUs) which allows a process to address more memory than it has virtual address space. Further, it works hand-in-hand with PAE as you by definition need PAE support in order for the OS to address memory higher than 4GB in the first place. However, in order to use AWE, the application has to be explicitly written to utilise it as the usage of AWE requires the application itself to take a far more active role in managing its memory. AWE support is indicated via a flag in the PE header of the application binary. Needless to say, a tiny minority of applications have this support. The only one I could name right now would be Microsoft's SQL Server.

4GT (4-Gigabyte Tuning)

This is one other Windows-specific capability that isn't really related to a discussion on 4GB limitations but inevitably will be raised regardless. While PAE provides for the OS to address more than 4GB of physical memory, and AWE provides for an application to address more memory than in its virtual address space, neither of these features increase the amount of addressable memory at any given time in an application (ie. AWE allows you to change your view of memory, but not address more than 2GB of memory simultaneously). A Windows process in 32-bit has a 2GB virtual address space, with the remaining 2GB mapped to the kernel address space. 4GT, in contrast to PAE and AWE does allow you to modify the address space available to a user-mode application. By providing the appropriate bootloader parameter you can modify the usermode/kernelmode split to skew it up to a maximum of 3GB/1GB user/kernel-mode respectively. This used to be done quite a lot on large Terminal Servers for example, or to optimise database servers, however, the ramifications of doing so need to be carefully understood. You are reducing the amount of memory available to the kernel, and so, memory hungry drivers may now fail to load, or worse, outright crash the system if they haven't been coded to properly handle low memory conditions.

EDIT: I forgot to mention, that like AWE, an application won't even use the increased address space 4GT provides unless it is marked as capable in its PE Header. Merely enabling the setting won't get you anything unless your application supports this capability. Firefox, as an example, is large address aware and being 32-bit, can thus address up to 3GB instead of 2GB. While on 32-bit systems this capability is not likely used (how many 32-bit Windows users have modified their bootloader parameters to support 4GT?) it is fully used on 64-bit Windows and can use the full 3GB address space out of the box. And god knows Firefox needs it...

In summary, in the age of x64, I tend to view all of the above as far more trouble than it's worth. The virtual address space of a Windows 64-bit process is currently 8TB. Windows 7 Professional and up give you 192GB of physical memory, while Windows Server 2008 R2 Enterprise and up give you up to 2TB. So if at all possible, avoid 32-bit, 64-bit is the solution; PAE, AWE & 4GT were only ever workarounds.

If any of the above is incorrect, please correct me, as it's been a while since I studied much of the above, and if anyone can shed more light on the Unix situation, I'd be interested (in a very nerdy way).