One can encrypt backups with keys that are "expire" (read: are thrown away) according to some schedule, so that they can have e.g. backups for the last year, but cannot read backups that are older than that. Should be pretty simple to set up, really.
KDE 4.1 was also lacking severely in comparison with 3.5. I'm running 4.1.96 aka 4.2rc1 and it looks far more complete though I must admit that I don't really run all that many KDE applications regularly.
On any modern system, the only real difference between a process and a thread is that threads share memory. Threads can be marginally faster because of this, but usually not enough to matter. (Yes, if you abuse the implicit memory sharing you'll end up with lots of heisenbugs, but that'll also happen if you abuse shared memory, mmaps, etc. in an n-process model. In either case there's no substitute for properly designed communication channels.)
You might argue that processes are theoretically more crash-safe since either can monitor the other, but that's only if you use low-level languages which allow you to crash a process (C and C++ come to mind) -- Erlang, for example, doesn't suffer from this. The only area where I've actually ever seen this crash-resistance exploited is in networked applications (mail daemon) and high-availability apps where I have a little commercial experience.
RAII doesn't force you to use direct heap allocation, you know. It is quite common to use memory pools and use RAII to ensure that pool element are accounted for correctly.
Alas, it's one of those that is very hard to reproduce, but it happens pretty reliably when X is under high load -- I originally thought it had to do with mouse grabs because it happened 100% reliably with VirtualBox and kvm, but I've now also seen it happen when X was loaded and nothing was grabbing the mouse. I've googled around and found lots of similar, but not quite identical reports of mouse problems.
(No, it's not that the device disconnects, nothing in the dmesg log about disconnects, the mouse pointer moves fine, the X server just doesn't receive any events -- as reported by xev. Strangely this is the case both with the hardware mouse cursor and the software mouse cursor.)
It's driving me nuts, so I'm going to try reporting it as an xorg bug (happens regardless of programs running, etc.), but I'm not hopeful that anyone will be able to track it down.
It's quite easy to allow restarts of the windowing system, you just have a proxy between the "talks to hardware" bit and the "talks to clients" bit (see "screen" for the equivalent console app). The proxy would obviously have to be simpler and less prone to errors, etc. for this to make sense, but such a proxy would not need access to any hardware, so that should be pretty doable.
It's particularly annoying if you have some intermittent problems with, say, the mouse disappearing and the only way to recover is to restart X. Being able to restart X without killing all the clients would change such a problem from "completely ruins my entire user experience" to "mildly annoying".
the word "observable". AFAIUI, in this case it means directly observable. Given an expanding universe -- since nothing can travel faster than light (and c is finite) and the universe has a finite age there is a limit to how far you can "see" in any direction from any given vantage point (see "horizon problem"). However, you might still be able to see an object at the very edge of "your" observable universe being influenced by something beyond your particular observation horizon -- that is, you can tell that it is being influenced by something and that it's not being influenced by something inside horizon. So essentially very talking about indirect observation here.
1. Boost. 2. Nonsense. Boost has facilities for this ("any", iirc) and also for something called "sum" types which can achieve what you want in a better way ("variant", iirc). 3. shared_ptr, weak_ptr. 4. Yup. Going to be fixed by C++0x. 5. C++ can be written to be a lot more portable than your Ruby or Python. 6. A matter of taste.
Upwards of 10% of all children aren't biologically related to their (supposed) fathers. The book "Sperm Wars" has a brilliant treatment of this and much much more (too effing lazy to link, so use google or something).
That'll teach me to leave out a "not". Of course, I meant "theoretically NOT 100% reliable".:)
The odds of collisions against a given fixed hash (which a hash for a data block is) of course depend on the method, but they are miniscule -- probably less than random bits flips on the bus or in RAM. Has anyone even ever found a single example of a SHA256 collision?
Even so, you can *NEVER* be absolutely 100% sure that the data is what you wrote. Even a two-way RAID1 doesn't get you there since you could (theoretically) have identical errors on both drives. Increasing it to a three-way RAID1 with a majority vote (or even just outright declaring an unrecoverable error when a mismatch is found) gets you closer to 100%, but errors are still theoretically possible.
So the point is: You can never attain 100%, but how close to 100% do you want to get? For me, ZFS hashes are "good enough".
ZFS checksums are actually hashes, as in "cryptographic hash", so they're pretty damn reliable (though theoretically 100% reliable) at detecting errors.
The output is still the best I've seen to date, but TeX is just an awful awful language to program -- which makes doing anything nontrivial an utter chore and insanely error-prone. Especially the macro parameter expansion... Oh, the Pain! Combine that with absurd and archaic limitations like the fixed-size stack/heap, etc. etc. and you have a complete nightmare.
One of the major points of the ZFS checksums is that the checksum for block X is stored in the block that points to X. In addition to ensuring that X is written properly is also ensures that writes actually go to the correct blocks.
(I swear, I'm not following you around, I just happened upon two of your posts:)).
The "special custody" is called "forvaring" (as I'm sure you know) and basically means that they are imprisoned indefinitely (without the possibility of parole) at the discretion of the court (iirc), but there is always a theoretical chance that they might be released. As you rightly say, this is usually reserved for extremely dangerous individuals and in practice very few (if any) people on "forvaring" are ever actually released.
You probably just need to limit your download or upload rate more to prevent excessive queueing at the ISPs routers. What I usually do is start by setting up a continuous download/upload and continuously pinging a server (or two) which is known to respond quickly to pings. Once you do that you can simply use a binary search (looking at the ping times as an indicator) to find out what your download/upload should be.
Slashdot Mirror
One can encrypt backups with keys that are "expire" (read: are thrown away) according to some schedule, so that they can have e.g. backups for the last year, but cannot read backups that are older than that. Should be pretty simple to set up, really.
KDE 4.1 was also lacking severely in comparison with 3.5. I'm running 4.1.96 aka 4.2rc1 and it looks far more complete though I must admit that I don't really run all that many KDE applications regularly.
On any modern system, the only real difference between a process and a thread is that threads share memory. Threads can be marginally faster because of this, but usually not enough to matter. (Yes, if you abuse the implicit memory sharing you'll end up with lots of heisenbugs, but that'll also happen if you abuse shared memory, mmaps, etc. in an n-process model. In either case there's no substitute for properly designed communication channels.)
You might argue that processes are theoretically more crash-safe since either can monitor the other, but that's only if you use low-level languages which allow you to crash a process (C and C++ come to mind) -- Erlang, for example, doesn't suffer from this. The only area where I've actually ever seen this crash-resistance exploited is in networked applications (mail daemon) and high-availability apps where I have a little commercial experience.
In what way?
I'll happily admit that I do prefer bzr for its UI, but I hardly think either is objectively "better", whatever that means.
that you can do this generically -- so you don't have to have the refcounting logic repeated all over the place.
RAII doesn't force you to use direct heap allocation, you know. It is quite common to use memory pools and use RAII to ensure that pool element are accounted for correctly.
It's probably not a good idea to read/write randomly to /dev/core or /dev/mem, for instance.
Alas, it's one of those that is very hard to reproduce, but it happens pretty reliably when X is under high load -- I originally thought it had to do with mouse grabs because it happened 100% reliably with VirtualBox and kvm, but I've now also seen it happen when X was loaded and nothing was grabbing the mouse. I've googled around and found lots of similar, but not quite identical reports of mouse problems.
(No, it's not that the device disconnects, nothing in the dmesg log about disconnects, the mouse pointer moves fine, the X server just doesn't receive any events -- as reported by xev. Strangely this is the case both with the hardware mouse cursor and the software mouse cursor.)
It's driving me nuts, so I'm going to try reporting it as an xorg bug (happens regardless of programs running, etc.), but I'm not hopeful that anyone will be able to track it down.
It's quite easy to allow restarts of the windowing system, you just have a proxy between the "talks to hardware" bit and the "talks to clients" bit (see "screen" for the equivalent console app). The proxy would obviously have to be simpler and less prone to errors, etc. for this to make sense, but such a proxy would not need access to any hardware, so that should be pretty doable.
Thanks for the SIGPWR hint, btw. Handy to know.
That's actually a great point.
It's particularly annoying if you have some intermittent problems with, say, the mouse disappearing and the only way to recover is to restart X. Being able to restart X without killing all the clients would change such a problem from "completely ruins my entire user experience" to "mildly annoying".
Is there anything they can't do?
Fuckin' worst interface ever.
the word "observable". AFAIUI, in this case it means directly observable. Given an expanding universe -- since nothing can travel faster than light (and c is finite) and the universe has a finite age there is a limit to how far you can "see" in any direction from any given vantage point (see "horizon problem"). However, you might still be able to see an object at the very edge of "your" observable universe being influenced by something beyond your particular observation horizon -- that is, you can tell that it is being influenced by something and that it's not being influenced by something inside horizon. So essentially very talking about indirect observation here.
As in: "Person X effected this change in policy.". The meaning is basically "make happen" or more literally "cause to happen".
1. Boost.
2. Nonsense. Boost has facilities for this ("any", iirc) and also for something called "sum" types which can achieve what you want in a better way ("variant", iirc).
3. shared_ptr, weak_ptr.
4. Yup. Going to be fixed by C++0x.
5. C++ can be written to be a lot more portable than your Ruby or Python.
6. A matter of taste.
and slightly scary point actually.
Upwards of 10% of all children aren't biologically related to their (supposed) fathers. The book "Sperm Wars" has a brilliant treatment of this and much much more (too effing lazy to link, so use google or something).
That'll teach me to leave out a "not". Of course, I meant "theoretically NOT 100% reliable". :)
The odds of collisions against a given fixed hash (which a hash for a data block is) of course depend on the method, but they are miniscule -- probably less than random bits flips on the bus or in RAM. Has anyone even ever found a single example of a SHA256 collision?
Even so, you can *NEVER* be absolutely 100% sure that the data is what you wrote. Even a two-way RAID1 doesn't get you there since you could (theoretically) have identical errors on both drives. Increasing it to a three-way RAID1 with a majority vote (or even just outright declaring an unrecoverable error when a mismatch is found) gets you closer to 100%, but errors are still theoretically possible.
So the point is: You can never attain 100%, but how close to 100% do you want to get? For me, ZFS hashes are "good enough".
ZFS checksums are actually hashes, as in "cryptographic hash", so they're pretty damn reliable (though theoretically 100% reliable) at detecting errors.
The output is still the best I've seen to date, but TeX is just an awful awful language to program -- which makes doing anything nontrivial an utter chore and insanely error-prone. Especially the macro parameter expansion... Oh, the Pain! Combine that with absurd and archaic limitations like the fixed-size stack/heap, etc. etc. and you have a complete nightmare.
What is eunt???
"Lux Aeterna" (find it and listen to it, and you'll understand.)
One of the major points of the ZFS checksums is that the checksum for block X is stored in the block that points to X. In addition to ensuring that X is written properly is also ensures that writes actually go to the correct blocks.
See the episode of Bullshit which Penn & Teller did on it. I'm sure you can find it on youtube (as least bits of it).
(I swear, I'm not following you around, I just happened upon two of your posts :)).
The "special custody" is called "forvaring" (as I'm sure you know) and basically means that they are imprisoned indefinitely (without the possibility of parole) at the discretion of the court (iirc), but there is always a theoretical chance that they might be released. As you rightly say, this is usually reserved for extremely dangerous individuals and in practice very few (if any) people on "forvaring" are ever actually released.
Actually it might be less effective (Danish, can't be bothered to find an English version).
You probably just need to limit your download or upload rate more to prevent excessive queueing at the ISPs routers. What I usually do is start by setting up a continuous download/upload and continuously pinging a server (or two) which is known to respond quickly to pings. Once you do that you can simply use a binary search (looking at the ping times as an indicator) to find out what your download/upload should be.