Wow, I hate that sentence. I don't think I've ever seen it used properly here. The correct objection in this case is: "one data point does not indicate a correlation."
Fair enough; I chose my words poorly. I meant "coincidence" rather than "correlation", really.
No, I mentioned both because I suspect larry bagina is confused. A "millionaire" is someone who has a net worth of $1 million or more, while the tax code is probably based on income instead.
My net worth is significantly less than it was a year ago, but my income hasn't changed.
I'm not confused. Wake up - you're just lucky. Many people have lost income; some of my friends have been laid off.
However, the fact is that many people from Maryland do flee to Deleware or Virginia to pay lower income taxes or property taxes.
Last year, Maryland raised marginal tax rate on millionaires. This year, the number of millionaires in Maryland dropped by 30% and total tax revenue collected from them dropped as well.
You seem to be trying to lead readers into believing that the tax increase caused the drop in millionaires. If so, you're badly mistaken or dishonest, and judging by your post's score some people were stupid enough to fall for it.
Correlation is not causation! larry bagina failed to mention other, more significant factors. Namely that we're in a recession! The S&P 500 index went down 36% between 2008-01-01 to 2009-01-01! Many, many, many people's income and net worth has gone down (though not all of us were so lucky as to be above $1 million to begin with), and tax revenue has fallen all across the US! Several major states are broke! Given the economic climate, it's ridiculous to even suggest that the tax increase is at all related to the drop in millionaires without doing much better, such as:
showing theoretically that the tax increase was significant enough to cause so many people to no longer be millionaires.
showing that many millionaires have moved out of Maryland.
using a comparable state with no tax increase as a control, demonstrating that Maryland's fall was much greater. (This is hard, though, because there are so many things different between states, so it's a tough argument to make that another is "comparable".)
Frankly, I wouldn't expect the CEO to have the keys. I'd expect it to be largely in the hands of senior IT staff.
Sounds like that's the root of our disagreement - when I think of a small business, I think of one that doesn't have five IT people, much less senior IT people.
Public-key cryptography to the rescue! You can encrypt the file in such a way that any of a set of private keys can decrypt it. You can also encrypt it in such a way as that a combination of keys are needed (i.e. 5 keys used in encryption, and you must have 2 in order to decrypt.)
Didn't Bruce Schneier once say "If you think cryptography can solve your problem, then you don't understand your problem and you don't understand cryptography"?
I don't think this solution is nearly as good as the envelope system. In particular, I don't expect the company owner or the CEO of the average small to medium business to have the expertise keep their private key files and password accessible to them and no one else. That means that either you're actually relying on two out of the other three keys being available (if those two fail to keep their private key files accessible to themselves) or you have poor security (if those two fail to keep their private key files accessible to no one else), whichever is worse.
In contrast, all of the trusted people probably know how to keep a physical key reasonably secure and accessible, and if you use a deposit box at a bank there may be identity checks as well.
In general, if your solution requires detailed technical knowledge from non-technical people, your solution is broken. Pick something low-tech instead.
DTrace has had most of these features since at least 2005, and SystemTap still doesn't have them in 2009. People who say SystemTap is equivalent to DTrace are just disconnected from reality.
In distros like Fedora, which include utrace, you already can use systemtap to probe both the kernel and userspace without problems (sure, it lacks the "final polish" of dtrace, but all the hard has been done)
Really? Are there probe points for userspace method entry and exit? Is there a way for dynamic languages to add probesets like the
dtrace jvm agents? I haven't seen anything like that. Got an example?
I'm looking around a bit, and this LWN article on utrace doesn't make it clear to me what actual functionality exists today.
They did call a quorum, at the beginning of bringing it to the floor, with 500+ members present, almost 41 hours before the vote, then they were told the vote would be first thing next week, so almost everyone went home. Sadly in France there is no easy way for a member to force a quorum call at a later point. This was an abuse of the rules.
That's bizarre. Why don't they just use the results of the vote to establish quorum? It would be more efficient and would eliminate this loophole. If only 16 people are marked as yea/nay/abstain, there was clearly no quorum, and the vote should be discarded.
Then you probably want to read: Patrick Logan on why SMT isn't "awesomez" [blogspot.com].
I think I'm stupider for having read that. If something can be judged by the quality of the arguments against it, then STM is indeed awesome. That post contained no actual data to support its assertion, just cherrypicked quotes of other people making the same assertion without data. It didn't meet even my rather low standards for articles linked from slashdot comments.
The ext4 people have kindly illuminated the problem. Now it is time to define a solution. Maybe it will be some sort of barrier logic, maybe a new kind of sync syscall. But it needs to be done.
#
# If I overwrite or append just a few bytes of an existing file and lose power before calling fdatasync(), what is guaranteed about the contents of the file?
I'd like to know which of the unmodified bytes are guaranteed to be preserved. None of them? All of them? Ones not in the same block as new bytes? (And what's a block? Is it st_blksize, or is it possible that block size varies within the file or changes over time?)
Rewriting the same file over and over is known for being risky. The proper sequence is to create a new file, sync, rename the new file on top of the old one, optionally sync.
Except on Linux you must sync the parent directory as well. None of this behavior is usefully documented anywhere, so it's upsetting when kernel developers tell application developers they're doing it wrong.
I've RTFPS (well, not quite - the Single Unix Specification; where do I find the Fine POSIX Spec free online?).
I am...dissatisfied with this answer because POSIX appears to provide so few guarantees that applications basically have to assume more than it promises to get anything done. The Linux documentation doesn't appear to promise anything more. For instance,
If I create a new file and fsync it, am I guaranteed that it hit disk? (Hint: on Linux this isn't true according to the #ifdef linux block of this file. It says I must fsync the directory, and nothing in Posix even says it's possible to open() or fsync() a directory; you have to use opendir().)
If I overwrite or append just a few bytes of an existing file and lose power before calling fdatasync(), what is guaranteed about the contents of the file? If you say "nothing", the only safe approach to updating anything is to write a complete replacement for the file, fsync() it (but pay attention to the special Linux case described above), and rename() it into place. Of course, that's a pretty significant performance hit and basically screws over any reasonable way of implementing shadow paging or write-ahead logging.
So...where is the specification that describes the filesystem's behavior in a useful way?
Or you can set up your MSA's on any random port, it doesn't really matter. My personal mail server accepts connections on SMTP, SMTPS, submission, and two other random ports just in case the above are blocked.
That works, of course, but there are benefits to standardization, among them reduced user confusion.
What ISPs have you encountered that block port 587 but allow any of your others?
You can set up port 25 SMTP to require authentication for relay purposes, without having to configure end user's machines for another port.
You can set up a MSA (mail submission agent) on port 25, but Verizon users will not be able connect to it after this change. If you run a mail service, the practical effects of this change are (1) you will need to set up port 587 if you have any customers who get transit through Verizon and (2) you will receive less spam.
Verizon wants to stop customers from directly connecting to outside MTAs (mail transfer agents, which run on port 25). This will stop customers from sending spam from Verizon's network.
However, they need to allow customers to send mail to MSAs outside their network or customers will (rightfully) sue them for anticompetitive practices. The solution is to encourage use of a separate port for MSAs, port 587. This is outlined in RFC 2476.
Verizon's making a good move here. It will be a temporary inconvenience to some of their customers who will have to get their outside MSAs to set up the submission port, but that's a pretty small cost for stopping the spam.
No, it's not. Every TCP connection needs a unique (src IP, src port, dest IP, dest port) tuple, and there are only 2^16 possible ports. Assignment is becoming so limited in Asian countries that I've heard of so many people being put behind one IP that they hit this limit when accessing certain popular websites (which of course require port 80 and one of a small set of destination IPs).
It's about as guaranteed as anything in software gets. People focus on risks that are easy to statistically quantify, but the probability of failing due to an unanticipated bug is (though difficult to put a precise number on) much greater than that of a UUID collision. If fear of such a collision is stopping you from simplifying a design (and thus lowering risk of bugs), you are being penny-wise and pound-foolish.
I loaded up my CV in Word and discovered the formatting was fucked - my CV looked like shit. I never bothered to work out exactly what happened, but it seems some small difference in font rendering or spacing meant half the dates wrapped onto the next line, so the whole thing looked a mess. I gave up on OO, switched to Word and heard back from the very next job I applied for. Perhaps I screwed up, perhaps there are some compatibility options I should have used, but the fact of the matter is I used OO, selected "save as.doc" and didn't get what I expect.
It seems likely that you're guilty of a pet peeve of mine: brittle formatting. If so (the rest of my post assumes this), it's not an OpenOffice problem. It often happens when moving documents from one machine with Microsoft Word to another (different version, different OS, different fonts installed). You almost certainly have this problem even within the same editing session on the same machine when you make the tiniest change to your document, whether it's to formatting or content.
The solution is to use the tool properly. For example,
rather than hitting space a bunch of times until the date looks right-aligned, ask the word processor to right-align it. (If you have something on the left of the same line, you can use a right tab stop or a table to make both work properly.)
rather than hitting enter a bunch of times until you get a page break in the desired place, insert an explicit page break.
rather than hitting enter at the end of a bibliography line and manually intending the next line, telling the word processor that the first line should not be intended but subsequent lines should be.
rather than putting something at the top or bottom of each page by hand, use the headers and footers features.
rather than typing "see page 3", use a reference to autogenerate the page number of your target.
Any time you find yourself hitting the same key many times or correcting many like things after making changes to your text or formatting, you're doing it wrong. Learning to do it right will result in a much more pleasant and successful experience.
This requires an attitude change. Many people refuse to learn how to make documents properly; some because they're "not computer people"; some because they're geeks who don't like GUIs or writing in human languages. I find both attitudes disgusting. The "not computer people" spend all day every day in front of one, and the latter group do need to communicate with people and could easily learn the GUI or find an alternative (e.g. TeX). If efficient or quality is important, you need to take some pride in your work and learn. It's a poor workman who blames his tools.
The javascript is not compiled over-and-over again with the java compiler. Rhino is. Then Rhino emits java byte code which gets the hotspot/jit goodness.
Wasn't the original statement that the Java compiler (used to compile Rhino) produces "very suboptimal results"? I.e., the code it produces (Rhino's JavaScript compiler) is slow. That code is executed to compile JavaScript most/all times you visit a webpage. So, if true, that's a problem.
So the quality of the Java compiler is really not all that relevant, because the code compiled by the compiler only compiles the javascript code once, making the quality of the compiler effectively order(1)... and given sufficiently large N, nobody cares about k.
But N is tiny. Keep in mind that while benchmark wars are fun, they aren't what users (should) care about. The purpose of these newer JavaScript implementations is to make web browsing go faster. You typically go to many, many different webpages and don't stay on them very long. Individual webpages change their JavaScript over time as well. So JavaScript is frequently compiled, used for a short while, and thrown away.
I don't understand how it matters that she has grandchildren or how old she may be. She was convicted of fraud and other crimes, so the law she punish her the same.
If anything, it's an argument for locking her up. She's obviously not a positive example for her grandchildren, so why would the judge want them spending time with her?
Slashdot Mirror
Fair enough; I chose my words poorly. I meant "coincidence" rather than "correlation", really.
No, I mentioned both because I suspect larry bagina is confused. A "millionaire" is someone who has a net worth of $1 million or more, while the tax code is probably based on income instead.
I'm not confused. Wake up - you're just lucky. Many people have lost income; some of my friends have been laid off.
[citation needed]
You seem to be trying to lead readers into believing that the tax increase caused the drop in millionaires. If so, you're badly mistaken or dishonest, and judging by your post's score some people were stupid enough to fall for it.
Correlation is not causation! larry bagina failed to mention other, more significant factors. Namely that we're in a recession! The S&P 500 index went down 36% between 2008-01-01 to 2009-01-01! Many, many, many people's income and net worth has gone down (though not all of us were so lucky as to be above $1 million to begin with), and tax revenue has fallen all across the US! Several major states are broke! Given the economic climate, it's ridiculous to even suggest that the tax increase is at all related to the drop in millionaires without doing much better, such as:
Sounds like that's the root of our disagreement - when I think of a small business, I think of one that doesn't have five IT people, much less senior IT people.
Didn't Bruce Schneier once say "If you think cryptography can solve your problem, then you don't understand your problem and you don't understand cryptography"?
I don't think this solution is nearly as good as the envelope system. In particular, I don't expect the company owner or the CEO of the average small to medium business to have the expertise keep their private key files and password accessible to them and no one else. That means that either you're actually relying on two out of the other three keys being available (if those two fail to keep their private key files accessible to themselves) or you have poor security (if those two fail to keep their private key files accessible to no one else), whichever is worse.
In contrast, all of the trusted people probably know how to keep a physical key reasonably secure and accessible, and if you use a deposit box at a bank there may be identity checks as well.
In general, if your solution requires detailed technical knowledge from non-technical people, your solution is broken. Pick something low-tech instead.
I don't remember any Swahili grammar, but "Bad tin/can please I feel cold call a doctor?" Huh?
Ahh, the SystemtapdtraceComparison answered my question: systemtap can do nothing.
Systemtap lacks the following features dtrace has:
DTrace has had most of these features since at least 2005, and SystemTap still doesn't have them in 2009. People who say SystemTap is equivalent to DTrace are just disconnected from reality.
Really? Are there probe points for userspace method entry and exit? Is there a way for dynamic languages to add probesets like the dtrace jvm agents? I haven't seen anything like that. Got an example?
I'm looking around a bit, and this LWN article on utrace doesn't make it clear to me what actual functionality exists today.
That's bizarre. Why don't they just use the results of the vote to establish quorum? It would be more efficient and would eliminate this loophole. If only 16 people are marked as yea/nay/abstain, there was clearly no quorum, and the vote should be discarded.
I think I'm stupider for having read that. If something can be judged by the quality of the arguments against it, then STM is indeed awesome. That post contained no actual data to support its assertion, just cherrypicked quotes of other people making the same assertion without data. It didn't meet even my rather low standards for articles linked from slashdot comments.
+1 for a new fbarrier(2) syscall.
Yes, you can open() a directory on Mac OS X. That in no way contradicts my statement about the standard.
Where did you get that idea? At least in the version I saw (http://www.unix.org/single_unix_specification/), the open documentation does not mention O_SEARCH or directories at all.
The Subversion code I linked to explicitly said that opening a directory fails on some platforms, so your expectation is incorrect.
I'd like to know which of the unmodified bytes are guaranteed to be preserved. None of them? All of them? Ones not in the same block as new bytes? (And what's a block? Is it st_blksize, or is it possible that block size varies within the file or changes over time?)
Except on Linux you must sync the parent directory as well. None of this behavior is usefully documented anywhere, so it's upsetting when kernel developers tell application developers they're doing it wrong.
I've RTFPS (well, not quite - the Single Unix Specification; where do I find the Fine POSIX Spec free online?).
I am...dissatisfied with this answer because POSIX appears to provide so few guarantees that applications basically have to assume more than it promises to get anything done. The Linux documentation doesn't appear to promise anything more. For instance,
So...where is the specification that describes the filesystem's behavior in a useful way?
I've never seen any "rock-solid software" of any kind, but at least the Open Source stuff I can fix by myself when needed.
That works, of course, but there are benefits to standardization, among them reduced user confusion.
What ISPs have you encountered that block port 587 but allow any of your others?
You can set up a MSA (mail submission agent) on port 25, but Verizon users will not be able connect to it after this change. If you run a mail service, the practical effects of this change are (1) you will need to set up port 587 if you have any customers who get transit through Verizon and (2) you will receive less spam.
Verizon wants to stop customers from directly connecting to outside MTAs (mail transfer agents, which run on port 25). This will stop customers from sending spam from Verizon's network.
However, they need to allow customers to send mail to MSAs outside their network or customers will (rightfully) sue them for anticompetitive practices. The solution is to encourage use of a separate port for MSAs, port 587. This is outlined in RFC 2476.
Verizon's making a good move here. It will be a temporary inconvenience to some of their customers who will have to get their outside MSAs to set up the submission port, but that's a pretty small cost for stopping the spam.
If you want to see evidence they're working on delivering a Mac version, you might start at the Mac build instructions or the revision history.
No, it's not. Every TCP connection needs a unique (src IP, src port, dest IP, dest port) tuple, and there are only 2^16 possible ports. Assignment is becoming so limited in Asian countries that I've heard of so many people being put behind one IP that they hit this limit when accessing certain popular websites (which of course require port 80 and one of a small set of destination IPs).
It's about as guaranteed as anything in software gets. People focus on risks that are easy to statistically quantify, but the probability of failing due to an unanticipated bug is (though difficult to put a precise number on) much greater than that of a UUID collision. If fear of such a collision is stopping you from simplifying a design (and thus lowering risk of bugs), you are being penny-wise and pound-foolish.
It seems likely that you're guilty of a pet peeve of mine: brittle formatting. If so (the rest of my post assumes this), it's not an OpenOffice problem. It often happens when moving documents from one machine with Microsoft Word to another (different version, different OS, different fonts installed). You almost certainly have this problem even within the same editing session on the same machine when you make the tiniest change to your document, whether it's to formatting or content.
The solution is to use the tool properly. For example,
Any time you find yourself hitting the same key many times or correcting many like things after making changes to your text or formatting, you're doing it wrong. Learning to do it right will result in a much more pleasant and successful experience.
This requires an attitude change. Many people refuse to learn how to make documents properly; some because they're "not computer people"; some because they're geeks who don't like GUIs or writing in human languages. I find both attitudes disgusting. The "not computer people" spend all day every day in front of one, and the latter group do need to communicate with people and could easily learn the GUI or find an alternative (e.g. TeX). If efficient or quality is important, you need to take some pride in your work and learn. It's a poor workman who blames his tools.
Wasn't the original statement that the Java compiler (used to compile Rhino) produces "very suboptimal results"? I.e., the code it produces (Rhino's JavaScript compiler) is slow. That code is executed to compile JavaScript most/all times you visit a webpage. So, if true, that's a problem.
But N is tiny. Keep in mind that while benchmark wars are fun, they aren't what users (should) care about. The purpose of these newer JavaScript implementations is to make web browsing go faster. You typically go to many, many different webpages and don't stay on them very long. Individual webpages change their JavaScript over time as well. So JavaScript is frequently compiled, used for a short while, and thrown away.
If anything, it's an argument for locking her up. She's obviously not a positive example for her grandchildren, so why would the judge want them spending time with her?