The first thing you need to know about RAID5 is that it's pretty unreliable; if you lose one device (and subsequently replace it) then the array has to read every sector from every other device in order to rebuild the data. Any unrecoverable sector error on any device will result in a corrupt sector in your rebuilt array.
RAID1 duplicates devices, although your storage requirement is now 2x the quantity of data being stored (as opposed to say 1.25x), the chance of error on rebuild is a lot smaller.
However, all inexpensive RAID solutions suffer from the problem that your devices are on a single server - they're a single point of failure, and if, for example, your server's power supply fails and fries the parts in the case, all copies of your data may be destroyed.
To mitigate that problem you could try a distributed filesystem. Your files would actually be distributed among multiple servers and the filesystem would ensure replication.
MogileFS is one such, although it does not provide a POSIX filesystem view it is nevertheless pretty easy to use. There are various distributed filesystem projects around, including
Ceph,
Kosmos,
and
Venti.
Although these projects are at varying stages of completeness and you may need to be a bit brave to trust them with your important data, the promise of distributed filesystems is high availability and extensibility.
Plus, when their server (singular?) finally responded to me, it requires a later version of Flash than I have. So I can't read the presentation at all. Way to not get the word out, folks.
I've got a Unicomp keyboard with the inbuilt trackpoint. The trackpoint works, but the mouse movement is too slow to be useful. So I use a 2nd mouse.
Also the left and right mouse buttons (on the keyboard) stopped working.
When I first got the keyboard, the Esc key didn't work. How am I supposed to use vim like that? Fortunately it started working after I hit it about 1000 times. But it's a sad story to tell about Unicomp's quality control.
If this Model M dies, I've got several more around the house.
You are about to send sensitive data to a third party who will load it into a new
database and send you back the database. That's insane.
You need to bring the destination (the database) in-house. Either load the data yourself, or get the consultant to come in-house to load the data. Under no circumstances should the sensitive data travel outside your network boundary. It's not a question of "how strong is my encryption" at all.
The limit rule runs first, accepting an average of 1 syn packet per minute. If the
rate is exceeded then the rule fails and the DROP rule runs, which drops all further attempts to connect to ssh.
No, because of his unbelievable testimony. I'm unable to comprehend why the GGP of this post thinks that a judge alone is likely to be more lenient than this jury was. The judge was clearly not impressed with Reiser's behaviour during the trial and there's no reason to believe that the judge found Reiser's evidence any more compelling than the jury did.
Unit tests aren't of much worth to Knuth because he writes the code once, tests it whichever way he wants to, and publishes the code in his book. Once it's published he doesn't need to change it ever again, or perhaps only if he brings out a new revision of the book - in which case he can test the new version.
Code (subroutines, functions, methods) in the real world need to interoperate with a lot of other code - calling code and called code. In the real world, code changes are always occurring and so it is necessary to re-test if changed code still works (unit test) and if the contracts between two pieces of dependent code are still followed (probably also done as part of a unit test). Automating unit tests by writing code for them means that the re-testing can be done with minimal re-work.
I think the salient point is that each successive iteration of the code already contains the lessons learned from the previous iteration. There is no need to go away and redesign the system because it's design has already been morphed through the iterations.
In fact, a further redesign might have the effect of undoing some of the lessons learned, and itself require one or two improvement cycles before it is good.
I will rephrase it for you. The ancient Greeks believed that everything that happened was caused by one or more Gods. If the winter was particularly cold, it was because some God did it. If you stubbed your toe, it was punishment from a God. As time passed and we learned more about how things work, we formulated laws of physics which predict very accurately how physical things behave and the physical state of a system changes over time. The laws of physics have no need for a hidden God to make things happen in the universe - stars shine due to the nuclear reactions of their constituent atoms under gravitational pressure, not because a God made them do it, and so on.
Current theories of the origin of the universe posit that when you trace the current state of the universe back in time you reach a singularity about 13.7 billion years ago, in which the laws of physics break down, and particularly beyond which the concept of Time does not exist. Creationists seize upon that singularity and assert that "because we don't understand what happened at or before the singularity, that must mean that God created the universe!". This is a weak argument no better than the ancient Greeks could muster - because we don't understand something, God must be the reason.
But my point on irrelevance was that current physical laws do not require the existence of a God. We don't know how the singularity worked, but whether it was caused by a God or not does not affect the universe today.
And it should be obvious that Hawking and other cosmologists are not studying the beginning of the universe to look for the existence of any God.
If you want to find a God, look inside yourself, because you won't find one in the universe.
It's not an important distinction because the set of all possible Gods is infinite, but Theists rarely believe that any kind of a God exists, they believe in their specific flavour. Jehovah, Allah, Zeus, Osiris, Freya, Thor, Ahulane... there's no specific evidence to support the existence of any of them.
Likewise when you look in detail at the behaviour of the universe and physics, there's no need for a God of any kind to keep it all running. Whether there was a need for a God to start it all 13.7 billion years ago is irrelevant today.
For all his putative omnipresence, God is as elusive as the Unicorn. There's no more reason to believe in any God than there is to believe in Unicorns.
A monopoly is bad for everybody except the monopolist.
I'm not out to get "office suite marketshare", but a win for Microsoft on OOXML will cause significant problems for me and everybody else... except Microsoft.
Haven't Microsoft already caused enough damage in the world?
So... what are the ISPs paying for, if they aren't the ones being sued and they aren't the ones sharing the music?
I can see it like through a crystal ball... the first user of one of these ISPs who gets sued, their lawyer is going to demand an accounting of all the ISP fees - and since the user is paying the fee (indirectly), the user is entitled to the benefit of indemnification.
Pity I used all my mod points before reading the parent post; it deserves informative or insightful.
I'm afraid I don't see the need for "mapping between OOXML and ODF". Mr Durusau might consider this a long-term viewpoint but I consider the long-term goal to be one standard document format which is usable by everybody, and I don't see how approval of a second document format can ever be a step toward this goal.
The technical problems with OOXML have been widely documented. There's no technical reason to make this a standard.
Mr Durusau's arguments are all political. If he wants to improve ODF then he had better make changes to the ODF standard, not mess around with OOXML. The political arguments are weak. Conciliation with Microsoft never improved Microsoft's behaviour. Even after fines of millions of Euros, Microsoft pays only lip service to the concepts of interoperability, documentation and standardisation.
If OOXML passes, then Microsoft will have been handed an unbeatable position in the marketplace. Governments will be happy to buy (or upgrade) MS-Office knowing that it supports an international standard. Other software will struggle to use the format, having to trade-off compliance with the standard versus replication of Microsoft's bugs. Microsoft, as already documented, is unlikely to participate in the standards maintenance process. They will embrace and extend their own format, and eventually extinguish the standard - when it no longer documents any current product.
If OOXML passes, it has a lifetime of 2-3 years only. That's how long it will take Microsoft to make it obsolete through a new version of Office. In the end, only Microsoft wins. Everybody else loses.
That may be so, but there are different risks involved.
The first, that "nobody will steal anything because they're all professional" is a true statement until somebody breaches the trust that other employees obviously have. You could ignore the risk until something goes missing, but do you want to be the first one affected by theft? Think of it as a trade-off. You're trading off the benefit of leaving your wallet out in the open versus the risk of somebody taking it. If your wallet is taken you are likely to be mightily inconvenienced - not just the stolen cash, but you also have to cancel your credit cards. If your keys are taken you have to change your home locks. And so on. IMHO, the balance of the cost-benefit equation for a wallet falls firmly on the side of "the benefit is small but the inconvenience of a problem is large".
The second risk is that objects or data may be accessed and returned, and you'd never know it. Does that USB thumb drive contain sensitive information, information which all employees are not entitled to access? You wouldn't know if somebody took the drive, copied its contents and returned it. Or if they copied your credit card number (or even scanned your card's mag stripe). If you lose a wallet you can take positive steps to mitigate the inconvenience - steps which you cannot take if you don't know there's been a breach of trust.
I think the OP's best strategy is to minimise the amount of personal kit which needs to be used in the office and left overnight. If the company owns the laptop and monitors then retention of the physical device becomes the company's responsibility. I don't see why the USB thumb drive needs to be used overnight - don't computers have their own storage?:-)
Slashdot Mirror
It isn't necessary for every user to check every piece of software.
If somebody does something malicious then it needs only one person out of the whole FOSS ecosystem to notice it and raise the alarm.
The first thing you need to know about RAID5 is that it's pretty unreliable; if you lose one device (and subsequently replace it) then the array has to read every sector from every other device in order to rebuild the data. Any unrecoverable sector error on any device will result in a corrupt sector in your rebuilt array.
RAID1 duplicates devices, although your storage requirement is now 2x the quantity of data being stored (as opposed to say 1.25x), the chance of error on rebuild is a lot smaller.
However, all inexpensive RAID solutions suffer from the problem that your devices are on a single server - they're a single point of failure, and if, for example, your server's power supply fails and fries the parts in the case, all copies of your data may be destroyed.
To mitigate that problem you could try a distributed filesystem. Your files would actually be distributed among multiple servers and the filesystem would ensure replication. MogileFS is one such, although it does not provide a POSIX filesystem view it is nevertheless pretty easy to use. There are various distributed filesystem projects around, including Ceph, Kosmos, and Venti.
Although these projects are at varying stages of completeness and you may need to be a bit brave to trust them with your important data, the promise of distributed filesystems is high availability and extensibility.
I expect we'll see development of protocols more robust than TCP to a MITM attack (this is ultimately a MITM denial of service).
Some kind of problem with their Engrams
Better check what KSW says to do when slashdotted ...
That's for sure.
Plus, when their server (singular?) finally responded to me, it requires a later version of Flash than I have. So I can't read the presentation at all. Way to not get the word out, folks.
I've got a Unicomp keyboard with the inbuilt trackpoint. The trackpoint works, but the mouse movement is too slow to be useful. So I use a 2nd mouse.
Also the left and right mouse buttons (on the keyboard) stopped working.
When I first got the keyboard, the Esc key didn't work. How am I supposed to use vim like that? Fortunately it started working after I hit it about 1000 times. But it's a sad story to tell about Unicomp's quality control.
If this Model M dies, I've got several more around the house.
So ... the terrorists have already won?
You are about to send sensitive data to a third party who will load it into a new database and send you back the database. That's insane.
You need to bring the destination (the database) in-house. Either load the data yourself, or get the consultant to come in-house to load the data. Under no circumstances should the sensitive data travel outside your network boundary. It's not a question of "how strong is my encryption" at all.
Best. Analogy. Ever.
What you are doing here is dropping only one packet per minute (with a maximum burst of 5 by default). The opposite of what you intended.
To make it work the way you intended, you need two rules:
iptables -I INPUT 1 -p tcp --dport 22 --syn -m limit --limit 1/minute -j ACCEPT
iptables -I INPUT 2 -p tcp --dport 22 --syn -j DROP
The limit rule runs first, accepting an average of 1 syn packet per minute. If the rate is exceeded then the rule fails and the DROP rule runs, which drops all further attempts to connect to ssh.
Yes, then we'd be able to fix why it uses 100% CPU time most of the time.
No, because of his unbelievable testimony. I'm unable to comprehend why the GGP of this post thinks that a judge alone is likely to be more lenient than this jury was. The judge was clearly not impressed with Reiser's behaviour during the trial and there's no reason to believe that the judge found Reiser's evidence any more compelling than the jury did.
The judge said that Reiser was rude and arrogant and other unstated (but obviously bad) things. I think the judge would have found him Guilty too.
Unit tests aren't of much worth to Knuth because he writes the code once, tests it whichever way he wants to, and publishes the code in his book. Once it's published he doesn't need to change it ever again, or perhaps only if he brings out a new revision of the book - in which case he can test the new version.
Code (subroutines, functions, methods) in the real world need to interoperate with a lot of other code - calling code and called code. In the real world, code changes are always occurring and so it is necessary to re-test if changed code still works (unit test) and if the contracts between two pieces of dependent code are still followed (probably also done as part of a unit test). Automating unit tests by writing code for them means that the re-testing can be done with minimal re-work.
In fact, a further redesign might have the effect of undoing some of the lessons learned, and itself require one or two improvement cycles before it is good.
The Captain has known since 1986 that sound waves, particularly the very potent tones of Jimi at Berkeley, can destroy oncoming rockets.
Reference: Riders of the Storm
I will rephrase it for you. The ancient Greeks believed that everything that happened was caused by one or more Gods. If the winter was particularly cold, it was because some God did it. If you stubbed your toe, it was punishment from a God. As time passed and we learned more about how things work, we formulated laws of physics which predict very accurately how physical things behave and the physical state of a system changes over time. The laws of physics have no need for a hidden God to make things happen in the universe - stars shine due to the nuclear reactions of their constituent atoms under gravitational pressure, not because a God made them do it, and so on.
Current theories of the origin of the universe posit that when you trace the current state of the universe back in time you reach a singularity about 13.7 billion years ago, in which the laws of physics break down, and particularly beyond which the concept of Time does not exist. Creationists seize upon that singularity and assert that "because we don't understand what happened at or before the singularity, that must mean that God created the universe!". This is a weak argument no better than the ancient Greeks could muster - because we don't understand something, God must be the reason.
But my point on irrelevance was that current physical laws do not require the existence of a God. We don't know how the singularity worked, but whether it was caused by a God or not does not affect the universe today.
And it should be obvious that Hawking and other cosmologists are not studying the beginning of the universe to look for the existence of any God.
If you want to find a God, look inside yourself, because you won't find one in the universe.
The Flying Spaghetti Monster will whip both of them. At once.
It's not an important distinction because the set of all possible Gods is infinite, but Theists rarely believe that any kind of a God exists, they believe in their specific flavour. Jehovah, Allah, Zeus, Osiris, Freya, Thor, Ahulane ... there's no specific evidence to support the existence of any of them.
Likewise when you look in detail at the behaviour of the universe and physics, there's no need for a God of any kind to keep it all running. Whether there was a need for a God to start it all 13.7 billion years ago is irrelevant today.
For all his putative omnipresence, God is as elusive as the Unicorn. There's no more reason to believe in any God than there is to believe in Unicorns.
http://freethoughtpedia.com/wiki/Atheism
http://freethoughtpedia.com/wiki/Atheism_is_a_belief
(That's TPS as in Trireme Propulsion System)
A monopoly is bad for everybody except the monopolist.
I'm not out to get "office suite marketshare", but a win for Microsoft on OOXML will cause significant problems for me and everybody else ... except Microsoft.
Haven't Microsoft already caused enough damage in the world?
So ... what are the ISPs paying for, if they aren't the ones being sued and they aren't the ones sharing the music?
I can see it like through a crystal ball ... the first user of one of these ISPs who gets sued, their lawyer is going to demand an accounting of all the ISP fees - and since the user is paying the fee (indirectly), the user is entitled to the benefit of indemnification.
I'm afraid I don't see the need for "mapping between OOXML and ODF". Mr Durusau might consider this a long-term viewpoint but I consider the long-term goal to be one standard document format which is usable by everybody, and I don't see how approval of a second document format can ever be a step toward this goal.
The technical problems with OOXML have been widely documented. There's no technical reason to make this a standard.
Mr Durusau's arguments are all political. If he wants to improve ODF then he had better make changes to the ODF standard, not mess around with OOXML. The political arguments are weak. Conciliation with Microsoft never improved Microsoft's behaviour. Even after fines of millions of Euros, Microsoft pays only lip service to the concepts of interoperability, documentation and standardisation.
If OOXML passes, then Microsoft will have been handed an unbeatable position in the marketplace. Governments will be happy to buy (or upgrade) MS-Office knowing that it supports an international standard. Other software will struggle to use the format, having to trade-off compliance with the standard versus replication of Microsoft's bugs. Microsoft, as already documented, is unlikely to participate in the standards maintenance process. They will embrace and extend their own format, and eventually extinguish the standard - when it no longer documents any current product.
If OOXML passes, it has a lifetime of 2-3 years only. That's how long it will take Microsoft to make it obsolete through a new version of Office. In the end, only Microsoft wins. Everybody else loses.
The first, that "nobody will steal anything because they're all professional" is a true statement until somebody breaches the trust that other employees obviously have. You could ignore the risk until something goes missing, but do you want to be the first one affected by theft? Think of it as a trade-off. You're trading off the benefit of leaving your wallet out in the open versus the risk of somebody taking it. If your wallet is taken you are likely to be mightily inconvenienced - not just the stolen cash, but you also have to cancel your credit cards. If your keys are taken you have to change your home locks. And so on. IMHO, the balance of the cost-benefit equation for a wallet falls firmly on the side of "the benefit is small but the inconvenience of a problem is large".
The second risk is that objects or data may be accessed and returned, and you'd never know it. Does that USB thumb drive contain sensitive information, information which all employees are not entitled to access? You wouldn't know if somebody took the drive, copied its contents and returned it. Or if they copied your credit card number (or even scanned your card's mag stripe). If you lose a wallet you can take positive steps to mitigate the inconvenience - steps which you cannot take if you don't know there's been a breach of trust.
I think the OP's best strategy is to minimise the amount of personal kit which needs to be used in the office and left overnight. If the company owns the laptop and monitors then retention of the physical device becomes the company's responsibility. I don't see why the USB thumb drive needs to be used overnight - don't computers have their own storage? :-)