throwaway0010

Yes and the responses are implemented with methods. Always.

The coke bit has regional variance. In the entire southern US "coke" is a fully generic term for all carbonated beverages: http://laughingsquid.com/soda-pop-or-coke-maps-of-regional-d...

Wikipedia lists "Coke" among marks that, while still protected, are often used generically: http://en.wikipedia.org/wiki/List_of_generic_and_genericized...

I think many marks on that list, including coke, could very well lose their status if someone were to bother to fight the legal battle.

And the object responds to the "foo" message by calling a method.

The difference is whether we're discussing the invocation or the response. OP's usage of method isn't incorrect in this case if it's discussing the response. It is true that all message responses (including accessors) are implemented using methods.

The source of the 30% statistic is from a selection-biased sample of people who undergo paternity testing because there is already a question as to who is the father. It's not an accurate figure.

The actual rate is likely somewhere between 1-3%.

More detail here: http://www.straightdope.com/columns/read/2730/whos-your-dadd...

Sure, but you can say the same about going to bed at night with the intent of waking up in the morning.

It is. Cgroup provides limits for memory, CPU time. We already have other accounting mechanisms for processes/threads (rlimits) and for inodes and disk space (disk quota systems). We've had those for ages. I imagine there will be more work to integrate these various accounting mechanisms with cgroup as the work continues.

Interestingly these programs are currently disallowed in California, I believe due mostly to Prop 103: http://www.consumerwatchdog.org/focusarea/prop-103-californi...

Indeed. I can negotiate a connection to google.com:80 successfully on a 1000ms latency pipe just fine. Slowly, but fine.

"Isn't that mainly terrorism, not paedophilia?"

It's nothing at all. Plenty of innocent people are on those lists having done nothing.

That the pretext is terrorism is irrelevant.

Interestingly the system you describe, marking two points and measuring time between them is illegal in California:

Definition of a speed trap: http://www.dmv.ca.gov/pubs/vctop/d17/vc40802.htm

Speed traps are prohibited: https://www.dmv.ca.gov/pubs/vctop/d17/vc40801.htm

The only nonsense here is your belief that a hiring process can accurately predict future results. Hiring is incredibly difficult: Vast volumes of literature have been written on the subject. Mistakes are common; your idea that business ought not correct for mistakes is pure fantasy.

It's not really an analogy; The divide is still along similar racial lines. Civil asset forfeiture laws predominantly impact poor black or Hispanic people. Here's what the ACLU has to say: https://www.aclu.org/criminal-law-reform/civil-asset-forfeit...

" Asset forfeiture practices often go hand-in-hand with racial profiling and disproportionately impact low-income African-American or Hispanic people who the police decide look suspicious and for whom the arcane process of trying to get one’s property back is an expensive challenge. ACLU believes that such routine “civil asset forfeiture” puts our civil liberties and property rights under assault, and calls for reform of state and federal civil asset forfeiture laws."

'Unless a company has been completely asleep at the wheel, there is no scenario under which people will suddenly go "woah woah woah! these 200 people must go!".'

Of course there is. You're projecting this as black and white, but in reality performance is a curve and the company's economic context determines where that curve ends. Companies growing rapidly hardly ever fire. Companies faced with a squeeze (and perhaps a shortage of profitable work) will be willing to move higher and higher up the performance curve.

Your platitudes about morale are simply untrue. I mentioned before specific peers as counter-examples, so let's also name the company: Netflix has a policy of firing people who aren't top-level performers. It's flatly impossible to make these kinds of determinations reliably before a hire -- the ONLY way to maintain a team of A-level players is to fire people who you've hired and who turn out not to perform.

This is not theory, this is fact in practice. It works great. People who don't make it don't like it -- and that's largely unimportant. People who actually are A-level performers love it. It's great for morale.

http://www.businessinsider.com/henry-blodget-should-we-fire-...

"Mass firings, however justified, represent broken management"

I don't think you've supported this opinion very well. Here's a counterpoint: Hiring and firing are a completely normal part of a business cycle. Every company should expect to have some ratio of hiring to firing. And yes, a firing typically means imperfect hiring practice (which is not the same as imperfect management) -- but here's the key I believe you may not understand: The world is imperfect. We can bank on the fact that we make mistakes; we will always make mistakes.

Your other assertion that morale will suffer is empirically false. I know many folks at companies with this sort of practice in place and it boosts their morale because they don't feel like they're dragged down by under-performers. Maybe it lowers the morale of those who are under-performing, but that's not exactly a problem, is it?

You don't think businesses should fire under-performers? That's nuts.

"The motivation behind the new system call has more to do with chroot environments, where the device might not be available at all. "

Why wouldn't one simply create the appropriate device node inside the chroot? This argument strikes me as nonsense.

If the job is unnecessary why would it be a good idea to "save" it?

It's absolutely useful and it's telling that you think it is not.

Contribution is not a prerequisite for criticism. Deserved criticism, in this case.

Agreed. The name for this is "regulatory capture."

http://en.wikipedia.org/wiki/Regulatory_capture

> Also, C is extensively standardised

Not really, at least not in the sense that you mean here: The generation of machine code in shared objects. There is a distinct lack of definition between C syntax and the resulting machine code.

> The best advantage of writing libraries in C is that it allows the library to be usable via FFIs in many other languages.

You can create C shared objects from Rust (or from a ton of other languages which generate native code). No big deal. It can do what you want.

Most of the non-technical people I know are very VERY upset with facebook and privacy, but are still using it in much the same fashion as they're still using their AT&T phone or Comcast cable despite their distaste for policy.

There's a good deal of nuance to these sorts of questions. For example, police may look at your house from the street in the visible spectrum, but may not look at your house from the street in the infra-red spectrum without a warrant.

The objectionable part is that it's not a regional issue. Vampires chasing money are everywhere and will relocate to follow the cash teat. This would've happened anywhere in the USA.

A few popular database drivers use escaping under the hood for parameterized query arguments. mysql2 ruby gem (and any rails stack on top of it) for example.

I think you may have misunderstood. "Some" is certainly not "all" or even "most." We are discussing legality, not whether the practice is common.

But some theaters DO block cellphones -- by encasing the venue in a faraday cage. It's possible to buy paint with metallic bits to block radio.

Broadcasting to jam is illegal. It is not illegal to build a room in which cellphones do not work, nor should it be.

Depends on scale. For startups with small datasets and low traffic, hardware is cheaper.

When traffic and data ramp up, 150k for a guy to cut your capex by 10% sounds like a steal.

In a thriving economy, workers with problems can often get jobs. When the economy tanks and layoffs occur it's the most weak and vulnerable who are hit the hardest.

whoops, thanks!