Well, official policy requires that I include a 20MB image, name, phones, logo (a second image), department, identification number and a few other things that I probably forgot about.
My sig includes my name and department. (Oh, and I must remember to update my department by monday, it changed about a month ago.)
The US revolution was a funny thing. While the french started to question who should govern, and what are the limits on his power, the US went a step ahead, and decided that no government has the right to exist, unless the Constituion grants it that right.
You should study it if you are interested on the subject. Their revolution is quite interesting.
Most of the time, the proper way to incorporate those things is by assynchronous requests after the page loads.
Not everybody is lucky enough to get permission to do that with ads, but there is no reason to make the user wait those social network widgets to load before he can see your page.
You are right. I was overlooking that problem with the algorithm (one must have the checkpoint before it acks the message, otherwise the node can't restore to "any state after receiving the message").
But now that I've tought about it, transactions are way more interesting than I was assuming.
To be fair, the myth that SSL requires too much hardware is rooted on reality. It was once true, at the 90's.
That article has a big WTF:
So did Google just compromise speed for security? Definitely not.
That after explaining how SSL increases latency. And for supporting the stated fact that they didn't compromisse speed, the article comes with a pair of non-sequitours: Google uses chaches, and they optmized it to use much less memory.
(Just a note... Yes, SSL does increase latency, and no, it's not enough to notice in a well written page. But if you go making a ton of different connections, it will be quite noticeable.)
Also, with all the recent attacks against the PKI, I'm wondering how the you and the GP are concerned about people suddenly get interest in breaking HTTPS.
Why not 301? The 302 status is for when you may change your head later, so the client better keep using the same address again and again. With 301 it should only use the new addred from now on.
If you nodes communicate only through message passing (and you can compute anything by communicating only through message passing), when restoring a node if you restore any state after receiving or transmitting the last message, it can't make any difference.
But then, that algorithm is not viable. It creates a perfectly descentralized checkpoint, without needing any coherence, but it needs too many checkpoints. But between enforcing coherence only of a single node, and enforcing coherence of the entire computer there is a huge space with different trade-offs between the number of checkpoints and the cost of each one.
Alternatively, you can enforce transactions on each message. But that probably isn't universal due to dead-locks (I have no hard proff either way).
The checkpoint images must also be coherent. Otherwise, you have lost state.
That's the restriction that must be removed. If your program can work with non-coherent subsets of the checkpoint, you won't have this scalability problem. And it is something possible, for any computation.
Yet, I choosed a provider that gave me the things I care about. I have a nice SLA to rely upon, and I don't outsource configuration, because that is just stupid.
Yet, there it is somebody outsourcing configuration, and complaining that the provider won't configure the machines exactly the way he wants. Duh. You can be sure that if they were configuring the machines the way he wants, somebody else would be here, complaining about it.
Yes, wine does that. But I've never seen KDE running scripts that didn't have the execution bit set. I can't tell about mono, as I simply never installed it.
MS has a hold on the PC strong enough to survive several years, even if their management insist on their current suicide style of doing business. They can make a lot of problems even if they fail, and they can be a huge problem if they somehow get their heads over their shoulders.
Slashdot Mirror
Well, official policy requires that I include a 20MB image, name, phones, logo (a second image), department, identification number and a few other things that I probably forgot about.
My sig includes my name and department. (Oh, and I must remember to update my department by monday, it changed about a month ago.)
Good thing that Blackberry's OS isn't called Android.
What did you run twice? The XOR one time pad or the ROT-13?
The US revolution was a funny thing. While the french started to question who should govern, and what are the limits on his power, the US went a step ahead, and decided that no government has the right to exist, unless the Constituion grants it that right.
You should study it if you are interested on the subject. Their revolution is quite interesting.
You know you can fill the space taken by those widgets before loading them, right?
(I don't doubt any problem you may have had doing this, I'm just pointing it out.)
The native Windows API was always a mess, and the 64 bits API is a case of "what were they thinking?!" even when compared to the other Windows ones.
Yes, I agree.
It was a honest question. I wanted to kow if I was overlooking something,
By "breaking the PKI" I mean basicaly compromissing certificates (directly or by compromissing CAs). So, yes, I'm refering to all that.
Those are not an attack on TLS itself, but for most effects, they are enough alike.
Most of the time, the proper way to incorporate those things is by assynchronous requests after the page loads.
Not everybody is lucky enough to get permission to do that with ads, but there is no reason to make the user wait those social network widgets to load before he can see your page.
You are right. I was overlooking that problem with the algorithm (one must have the checkpoint before it acks the message, otherwise the node can't restore to "any state after receiving the message").
But now that I've tought about it, transactions are way more interesting than I was assuming.
To be fair, the myth that SSL requires too much hardware is rooted on reality. It was once true, at the 90's.
That article has a big WTF:
That after explaining how SSL increases latency. And for supporting the stated fact that they didn't compromisse speed, the article comes with a pair of non-sequitours: Google uses chaches, and they optmized it to use much less memory.
(Just a note... Yes, SSL does increase latency, and no, it's not enough to notice in a well written page. But if you go making a ton of different connections, it will be quite noticeable.)
Does breaking the PKI consist of break TLS?
Also, with all the recent attacks against the PKI, I'm wondering how the you and the GP are concerned about people suddenly get interest in breaking HTTPS.
Why not 301? The 302 status is for when you may change your head later, so the client better keep using the same address again and again. With 301 it should only use the new addred from now on.
Computers also have no greed.
If you nodes communicate only through message passing (and you can compute anything by communicating only through message passing), when restoring a node if you restore any state after receiving or transmitting the last message, it can't make any difference.
But then, that algorithm is not viable. It creates a perfectly descentralized checkpoint, without needing any coherence, but it needs too many checkpoints. But between enforcing coherence only of a single node, and enforcing coherence of the entire computer there is a huge space with different trade-offs between the number of checkpoints and the cost of each one.
Alternatively, you can enforce transactions on each message. But that probably isn't universal due to dead-locks (I have no hard proff either way).
That's the restriction that must be removed. If your program can work with non-coherent subsets of the checkpoint, you won't have this scalability problem. And it is something possible, for any computation.
That does address the problem. Once you each node saves its state to enough other nodes, you don't need to make a checkpoint anymore.
But then, you must write code that can work with just partial checkpoints, what is quite hard.
Well, it seems obvious that you need to distribute your checkpoints. Instead of saving the global state, you must save smaller subsets of it.
Now, writting a program that does that is no easy task. That's why it is a problem. But don't think it can't be solved, because it can.
Hell. There goes the argument about piracy being victimless...
You know, I outsource a server.
Yet, I choosed a provider that gave me the things I care about. I have a nice SLA to rely upon, and I don't outsource configuration, because that is just stupid.
Yet, there it is somebody outsourcing configuration, and complaining that the provider won't configure the machines exactly the way he wants. Duh. You can be sure that if they were configuring the machines the way he wants, somebody else would be here, complaining about it.
Yes, wine does that. But I've never seen KDE running scripts that didn't have the execution bit set. I can't tell about mono, as I simply never installed it.
(Failing != failed) && (going down != zero)
MS has a hold on the PC strong enough to survive several years, even if their management insist on their current suicide style of doing business. They can make a lot of problems even if they fail, and they can be a huge problem if they somehow get their heads over their shoulders.
No. But it seems there are a few points that you are making an effort to ignore. Because you just quoted them, but still don't acknowledge them.
That's priviledge escalation. A rootkit is a piece of malware that disgusses itself by installing hooks at system functions.
You can't run a program by just clicking OK on a browser dialogue. No Linux browser knows how to chmod a downloaded file.