Well, thank you. I suspected as much but I wasn't sure. I am honestly happy to hear this discussed openly, and I'm happy to hear any of my comments characterized as 'productive'.
(I'm male, by the way, if that makes it any easier to continue this discussion.)
I think the potted example on the web page is somewhat poor, as it seems to be a problem existing package management systems already solve.
The more interesting aspect is the sandboxing, and how this is great for one-off software runs where it isn't worth it to install the needed packages on your base system because they're logically just a unit with the software you're testing. You mention this, but I think you'd do well to make it more obvious.
This is also, and this is something you mention, a way of preserving historic software and data. Bundle a full CDE package with an emulator and you can keep running that program for even longer; in fact, it seems a CDE package could gradually grow layers as time demands, from moving a (user-mode) kernel in, to adding device emulation, to going the final step and making the package more-or-less a ship in a bottle running in full hardware emulation.
This could also grow into a way to run untrusted (or minimally-trusted) software in an iron box, not just a sandbox. But that is harder and probably not your preferred direction.
If you're really poor, it would likely be useful to know that hooking headphones up to the microphone jack gives you a usable microphone. Just speak directly into one of the earpieces.
Anarcho-capitalism is the only anarchy that is possible. All other forms require a state, regardless of whether it calls itself one, to enforce the "no property" dictate.
People can make bizarre assumptions without realizing it.
This advice assumes that it's safe to have a disk full of noise (even if you deny it's encrypted data) in your control. That is perhaps a safe assumption under all foreseen circumstances, but it needs to be considered.
Another piece of advice I see, to simply destroy all media that has ever held sensitive information, assumes that destroying media is safe, as opposed to being prima facie evidence of wrongdoing. Again, it might be safe in all circumstances under consideration, but the assumption needs to be made explicit and it needs to be considered.
My point is that all these unexamined assumptions are quite unprofessional and reflect poorly on the commentators.
> In large cities there is less than 82 MHz of white space available AFAIK.
So? Is everything about the large cities, all the time? Can't small cities and rural areas have one solution and big cities have another? (Of course, that's already what happened, so I'm really not getting how your comment is a valid criticism of this scheme.)
How long will it be before this software is cracked and Intel has to think harder about this stuff?
Also: IBM did the same kind of thing beginning in the 1960s with System/360 and System/370 mainframes, but I think there may have generally been hardware modifications involved.
This is somewhat old: The sysenter interface on x86 Linux is no longer experimental, and it's faster than the old int 0x80 interface as well. [1] However, going through either is a bad idea. Use glibc or similar instead:
1. Bad input values will at least potentially set errno, which allows more enlightening debugging sessions.
2. You don't have to reinvent printf and whatever other useful functions that are provided by libc and not the kernel.
3. You shouldn't be writing that much of your code in assembly anyway. Use C or something for most of the bulk and reserve assembly for the bottlenecks.
Anyway, here's more details on how system calls on x86 Linux work now: