I downvoted your first post because, much as I dislike Condoleezza Rice, what on earth does that have to do with an IPO? Even putting aside that it was factually wrong (no, her joining isn't "all they had to do", they have 10 years of work to show for it).
I downvoted your second comment because it's complaining about downvotes, and is making the completely incorrect (and really quite narcissistic) assumption that you getting downvoted means surveillance/privacy has lost priority.
> Not trying to be pessimistic but genuinely curious why so many people make the analogy to the dot com period.
Because most people are not creative nor critical thinkers and the extent of their brilliance is superficial pattern matching. To most people the dot-com bubble seems to fit all the patterns so by their logic it must have the same outcome. If you think critically about the differences of the crypto craze and the dot-com era, you’ll see how irrational it is to make a strong comparison.
Sorry, I don't believe being able to transfer large amounts of money around without having to trust or be limited by banks or governments is much concern to 'millions'.
There really aren't all that many people that have problems with that, who are that distrustful of existing infrastructure.
There are millions of millionaires in China alone that are very concerned about the future security and mobility of their money. Now consider India, Russia, Iran. This isn’t fiction.
This has been thrown around for years on the BTC scene, and it's just not a killer app. Nor do I believe that such people are willing to use cryptocurrencies for such transfers, in their millions.
And that's before we get on to whether it is moral to facilitate such anyway...
Or there may not be any long term winners in this arena as people realise just how bad most if this stuff is for actual transactions and consumer protection.
Whoa there. Calm down buddy. Before you bust out the pitchforks, he just asked them to post tweets. The cost to them is zero in money, and virtually zero in time.
Couple that with the fact that he was providing them with a free service and I only see a morally net positive contribution from him.
> He wasn't. He was just giving them an error message after they Tweeted what he wanted.
Did you read the entire post? His service is available to India right now. Their tweets helped make that possible. It’s strange to me that you hate someone who provides a valuable service to people.
> And they did! All these users started following Browserling and tweeting about it. But they still couldn't use Browserling or Whatsapp, it was just a new message in place of "fatal error".
> It’s strange to me that you hate someone who provides a valuable service to people.
I don't care enough about him to hate him. I just said I think he's an asshole.
> And they did! All these users started following Browserling and tweeting about it. But they still couldn't use Browserling or Whatsapp, it was just a new message in place of "fatal error".
> Then I got curious. Would these users tweet anything that I asked them? So I decided to troll my competitors a little bit, and asked users to tweet a popular meme Taiwan number one to them.
Then he seems to shift to actually trying to tell them when the service is available instead of pretending it will be if they send a tweet:
> Then instead of just tweeting and trolling, I asked users to start following Browserling on Facebook so I could reconnect with them and let them know when the software was up and running again.
And then finally he built something where they could sign up and it admitted they were building up server capacity to handle it. Then he moved to a lottery which it sounds like legitimately paid out, and he started to do legitimate monetisation of a not-entirely-firewall-blocked service.
At this point, both Intel and AMD press releases should be treated as highly, highly suspect. They are both jockeying to mitigate money loss or take advantage to make money. The truth is a secondary concern.
I'd believe CERT, project zero and the independent linux kernal devs if you want the truth.
> The concept of Fork was not designed to "spawn new programs", it was created to allow parallelism on a single program with several processes collaborating on the same task. It's even in the name (i.e. you fork the program in two, not spawn a new process).
I really doubt this. Is there an instance of a program with 1st edition lineage that use processes to achieve concurrency? There were pipes, sure, but that could be achieved with a spawn-like call.
I don’t see processes being used for concurrency in UNIX history until BSD sockets and forking servers emerged.
Well, yes, fork()/exec() and spawn-like things are capable of doing the same things, more or less.
On the other hand, shell pipelines were used for concurrency before BSD added networking code. And I have doubts that shell pipelines would have developed without the fork()/exec() model---see the author's Windows NT (and earlier) with really, seriously broken shell models.
Actually niche online communities aren’t weird. Just because a topic isn’t repeated over and over again on big media doesn’t mean it’s weird. Big media doesn’t dictate what is normal.
What's wrong with "weird"? It means: fateful, uncanny, magical. It's never properly been an insult, and those who misbelieve otherwise and deploy it in a pejorative fashion accidentally do that which they so label a favor by avoiding it - nothing ruins a small, special space like an influx of people who neither understand nor care what makes it special.
It's definitely good to be aware of what tricks you have. Sometimes you need to do weird things like treat memory as hostile, see this article about chrome sandboxing: https://lwn.net/Articles/347547/
> So that's what we do: each untrusted thread has a trusted helper thread running in the same process. This certainly presents a fairly hostile environment for the trusted code to run in. For one, it can only trust its CPU registers - all memory must be assumed to be hostile. Since C code will spill to the stack when needed and may pass arguments on the stack, all the code for the trusted thread has to [be] carefully written in assembly.
> The trusted thread can receive requests to make system calls from the untrusted thread over a socket pair, validate the system call number and perform them on its behalf. We can stop the untrusted thread from breaking out by only using CPU registers and by refusing to let the untrusted code manipulate the VM in unsafe ways with mmap, mprotect etc.
It's not even a 'weird trick'; early-stage bootloader code and embedded systems often have to execute before RAM has been configured. This is a useful way to gain a little working space.
I'm not an assembly programmer, but is it possible there are benefits to treating SSE or AVX registers as a contiguous on-core buffer that are unrelated to performance?
I don't have enough experience with XMM registers (and SSE4 in general) to know if this is actually {useful,possible}, but a hypothetical use might be creating and using cryptographic keys such that the important numbers are never stored in main memory. If e.g. a decryption key is ever present in RAM, it's probably possible to steal it with a cold-boot attack that copies all of RAM. Once you have the RAM dump, the key can probably be found very quickly:
for (secret_key_t *p = 0; p < RAM_SIZE; p++) {
decode_with_key(p);
}
This does require significant physical access, but it works. I seem to remember reading ~1.5 years ago about a turnkey forensics kit (bottle of refrigerant included) for doing cold boot attacks? Regardless, more ways to protect keys is could be really useful.
Registers may be stored to RAM (though there are often local register files in the CPU). If you're on a modern x86 platform, you may have encrypted memory support.
For Intel, look up SGX. For AMD, look up SEV. Each of these is way more secure than reliance on registers as secure scratch memory.
SSE registers will never get stored to ram without emitting explicit instructions (or getting an interrupt) to do so on any Intel/amd cpu as far as I know. It can be tricky to deal with such situations, but if you have a stretch of code where you can stop that registers can be used to hide data from memory.
That's why I said it's tricky to deal with interrupts, but possible if the effort is worth it to the use case. One could run the code in a kernel module which masked interrupts or use restartable sequences and cleared sse in the kernel when in certain code sections.
