So, should employees of a public university where the President's annual compensation exceeds $1 million receive a full state-funded pension for educating 16,000+ out-of-state students?"
Why do I get the feeling that this is a leading question?
What planet are you from? 80%? Complete fiction. Vermont Yankee is very reliable, and had, from 2003-2009, an amazing 92.6% capacity factor. Which gives an employee/Mwatt ratio closer to 1.09, which while still slightly higher than the solar plant, isn't particularly bad.
Are you implying that a user with account name "mdsolar" is spreading FUD about non-solar power sources? Why would he do that?
I've actually seen phtotos of a guy who thought he had some bitching Viking runes tatooed, and they were horribly mispelled (I will not divulge the nature of the error...
That's okay, the mere fact that you have an interesting anecdote adds volumes to this conversation. No need to share it, that would just be overkill.
If you read the article (I know, I know) you'll discover that 75% of the people in the region already have access to the site via package deals. So it's actually surprising that 35 people did sign up for it.
So the potential regional market is only 1/4 the size that it otherwise might have been? Think, without these other access deals, they might have gotten 140 people to sign up.
Doesn't matter. Contracts can't override the law, regardless of how hard they try to make you think they can. They can say they have the right to change service at any time and that you can't terminate, but that is simply not true.
If the service materially changes, you can terminate the agreement, regardless of how many times they tell you that you can't.
And if they fight you on this, sue. Oh, wait, you can't: you signed away your rights to do so in an arbitration clause in your plan contract.
Ok, but how is offsetof() macro defined? Using something very similar to &(((struct foo*)(void*)0)->bar)
Perhaps, but perhaps not. That expression might be safe for some implementations of C; if so, there's no reason for the library that ships with that implementation to use something along the above lines to implement the offsetof() macro. But that doesn't mean it's generally safe or portable code.
Your fundamental premise is wrong, anyhow; not every implementation uses that trick to define offsetof(). In fact, gcc defines a special extension to C/C++, __builtin_offsetof(), to do the work. (gcc is allowed to introduce this new keyword because the standard reserves identifiers starting with a double underscore to the implementation.)
&(((struct foo*)(void*)0)->bar) will also give the value of the offset of the bar field.
You're speaking with a voice of authority, which is dangerous because of how incorrect in general your post is.
Others have already pointed out that you are wrong about NULL. Here's precisely what the spec says about the argument to &:
The operand of the unary & operator shall be either a function designator, the result of a [] or unary * operator, or an lvalue that designates an object that is not a bit-field and is not declared with the register storage-class specifier.
(((struct foo*)(void*)0)->bar) in particular is none of those things, and your expression is not legal C.
Some apparent dereferences of null pointers are allowed. For instance:
void *a = 0; void *b = &(*a);
The above is legal not because dereferencing a null pointer is legal, but rather because of an explicit exception to the rule carved out in section 6.5.3.2 of the spec, which says that in this case, the & and * cancel, and "the result is as if both were omitted".
Your expression is neither safe nor portable. If you do need to check the offset of a field in a structure, use the standard library offsetof() macro -- that's what it's for.
Re:Users can't tell the difference
on
R.I.P. FTP
·
· Score: 2, Insightful
If you don't know that FTP refers to a specific protocol, you don't know enough to be running a web site.
This is akin to saying if you don't know what a carburetor does, you don't know enough to be driving a car. Now, some people believe this, too, but this statement, and yours, are wrong.
OpenDNS is "free-as-in-ad-driven". You don't have to pay for it, but they need to make their money somehow, so they have their own special page when you type an invalid domain in the location bar, with text ads on. Comcast, on the other hand, which the end user is already paying for, is trying to inflict the greedy bastard business model they use for TV (hooray for paying for content that's 1/3 ads!) on their ISP customers.
This distinction is true, but irrelevant in the context of this discussion. If someone is unhappy with a DNS server because it redirects invalid lookups, then it's actively unhelpful to suggest they use a different DNS server that does the same thing.
Go download the number histories and do some nCk calculations to see the expected vs actual outcomes on odd/even combinations, distribution of the numbers, etc.. Yeah, you probably won't win but you'll considerably increase your chances by playing the numbers that come up more often.
What this approach fails to consider is that there are two competing forces in games of chance. As you have noticed, there are "streaks", that is, certain numbers, patterns, distributions, etc. can get "hot". So yes, one approach you can take is to pick hot numbers. What you haven't noticed is that numbers and patterns can also become "due"; a number that hasn't shown up in a long time builds up potential, and must eventually show up again so that the law of large numbers will be maintained.
It is only by carefully considering the fragile balance between hot numbers and due numbers that a skilled lottery player can tilt the odds more in his favor, for example, by noticing that a large streak of even numbers is due.
If you're only interested in preaching to the converted, then you shouldn't. If you're trying to persuade people without strong opinions on the matter, mocking the companies involved and calling those who disagree "idiots" is probably not the best strategy.
The authors do not a problem with the reader translating a book aloud, but they have a problem with someone they have a contract with to sell text-only versions of a work (and with whom they have separate audio version contracts) selling text plus audio versions. It is a contract issue.
There's no issue. If I have a contract which allows me to sell frozen burritos, but not ready-to-eat burritos, selling frozen burritos along with a microwave (which turns them into ready-to-eat burritos) doesn't violate the contract.
Even if your analogy -- that cooking a burrito is akin to creating a derivative work -- is a good one, there is no law that gives a burrito-maker exclusive rights to derivative works based on his burrito. The author of a book does have that right, and absent a contract that waives this right, I don't see how this is as clear cut as you claim.
My two.emacs modifications I find essential follow.
First, turning off of obnoxious misfeatures:
(fset 'yes-or-no-p 'y-or-n-p) ; stop forcing me to spell out "yes" (setq inhibit-startup-message t) (setq backup-directory-alist '(("." . "~/.emacs-backups"))) ; stop leaving backup~ turds scattered everywhere
And second, stealing the beginning-of-line behavior from Dev Studio: if you invoke the command at the beginning of the line, advance to the first non-whitespace-character instead.
(defun dev-studio-beginning-of-line (arg)
"Moves to beginning-of-line, or from there to the first non-whitespace character.
This takes a numeric prefix argument; when not 1, it behaves exactly like \(move-beginning-of-line arg) instead."
(interactive "p")
(if (and (looking-at "^") (= arg 1)) (skip-chars-forward " \t") (move-beginning-of-line arg))) (global-set-key "\C-a" 'dev-studio-beginning-of-line) (global-set-key [home] 'dev-studio-beginning-of-line)
harvested logins of customers.
FTFA: Fellow hackers, relying on press reports claiming that customer data may have been compromised, are hitting up the duo for passwords to Comcast e-mail accounts, which they say they don't have. "Nobody was listening in on the ports to try and get usernames and password," says Defiant. "We could have, but we didn't." (On this point, Comcast and the hackers agree). You have to consider the sources here; both sides have something to lose by claiming usernames and passwords were stolen. If the boys admit to stealing accounts, they're looking at a harsher sentence when this all comes crashing down. If Comcast admits accounts could have been compromised in this attack, they are facing a rather nasty security-related PR problem.
Slashdot Mirror
Link please?
Why do I get the feeling that this is a leading question?
Are you implying that a user with account name "mdsolar" is spreading FUD about non-solar power sources? Why would he do that?
That's okay, the mere fact that you have an interesting anecdote adds volumes to this conversation. No need to share it, that would just be overkill.
It's obviously fraud. Adding a sarcastic "Uh" to your rhetorical question doesn't help make your point, though.
So the potential regional market is only 1/4 the size that it otherwise might have been? Think, without these other access deals, they might have gotten 140 people to sign up.
And if they fight you on this, sue. Oh, wait, you can't: you signed away your rights to do so in an arbitration clause in your plan contract.
Priorities.
I'm not sure if this is a troll or not, but just in case it isn't: openDNS does the same sort of hijacking.
The days of /. users proofreading their posts, and posting complete sentences.
Perhaps, but perhaps not. That expression might be safe for some implementations of C; if so, there's no reason for the library that ships with that implementation to use something along the above lines to implement the offsetof() macro. But that doesn't mean it's generally safe or portable code.
Your fundamental premise is wrong, anyhow; not every implementation uses that trick to define offsetof(). In fact, gcc defines a special extension to C/C++, __builtin_offsetof(), to do the work. (gcc is allowed to introduce this new keyword because the standard reserves identifiers starting with a double underscore to the implementation.)
You're speaking with a voice of authority, which is dangerous because of how incorrect in general your post is.
Others have already pointed out that you are wrong about NULL. Here's precisely what the spec says about the argument to &:
The operand of the unary & operator shall be either a function designator, the result of a
[] or unary * operator, or an lvalue that designates an object that is not a bit-field and is
not declared with the register storage-class specifier.
(((struct foo*)(void*)0)->bar) in particular is none of those things, and your expression is not legal C.
Some apparent dereferences of null pointers are allowed. For instance:
void *a = 0;
void *b = &(*a);
The above is legal not because dereferencing a null pointer is legal, but rather because of an explicit exception to the rule carved out in section 6.5.3.2 of the spec, which says that in this case, the & and * cancel, and "the result is as if both were omitted".
Your expression is neither safe nor portable. If you do need to check the offset of a field in a structure, use the standard library offsetof() macro -- that's what it's for.
This is akin to saying if you don't know what a carburetor does, you don't know enough to be driving a car. Now, some people believe this, too, but this statement, and yours, are wrong.
Hey, look, I made a Slashdot car analogy!
This distinction is true, but irrelevant in the context of this discussion. If someone is unhappy with a DNS server because it redirects invalid lookups, then it's actively unhelpful to suggest they use a different DNS server that does the same thing.
Do you even know what succeed means? Here's a hint: you failed to do it in your post.
Go download the number histories and do some nCk calculations to see the expected vs actual outcomes on odd/even combinations, distribution of the numbers, etc.. Yeah, you probably won't win but you'll considerably increase your chances by playing the numbers that come up more often.
What this approach fails to consider is that there are two competing forces in games of chance. As you have noticed, there are "streaks", that is, certain numbers, patterns, distributions, etc. can get "hot". So yes, one approach you can take is to pick hot numbers. What you haven't noticed is that numbers and patterns can also become "due"; a number that hasn't shown up in a long time builds up potential, and must eventually show up again so that the law of large numbers will be maintained.
It is only by carefully considering the fragile balance between hot numbers and due numbers that a skilled lottery player can tilt the odds more in his favor, for example, by noticing that a large streak of even numbers is due.
(Yes, I'm making fun of you.)
If you're only interested in preaching to the converted, then you shouldn't. If you're trying to persuade people without strong opinions on the matter, mocking the companies involved and calling those who disagree "idiots" is probably not the best strategy.
The authors do not a problem with the reader translating a book aloud, but they have a problem with someone they have a contract with to sell text-only versions of a work (and with whom they have separate audio version contracts) selling text plus audio versions. It is a contract issue.
There's no issue. If I have a contract which allows me to sell frozen burritos, but not ready-to-eat burritos, selling frozen burritos along with a microwave (which turns them into ready-to-eat burritos) doesn't violate the contract.
Even if your analogy -- that cooking a burrito is akin to creating a derivative work -- is a good one, there is no law that gives a burrito-maker exclusive rights to derivative works based on his burrito. The author of a book does have that right, and absent a contract that waives this right, I don't see how this is as clear cut as you claim.
My two .emacs modifications I find essential follow.
First, turning off of obnoxious misfeatures:
And second, stealing the beginning-of-line behavior from Dev Studio: if you invoke the command at the beginning of the line, advance to the first non-whitespace-character instead.
What, as opposed to being forced to as you are today?
Yeah, the big mystery of "natural flavors" on the ingredients lists is just how much natural flavors to use.
I hope under the glass trackpad there's a little display just like the iPhone's.
Presenting the new smitty97 MacBook Touch.
A link to DJB's essay on the issues of IPV6 adoption feels obligatory here.