You are right, you'd still need a "legacy" address to connect to "true" v4 servers, but that address would be all you need, while most operating systems, routers, client and server software could be, technically, all-v6 all-the-time by now.

It also sucks at having software/hardware stacks nearly as well debugged as those for ipv4, which means running ipv6 at all is a security risk.

Nobody would switch for sundry technical advantages. The main driver for conversion is that ipv4 addresses are scarce. As soon as "we" seriously "move to ipv6", however, the scarcity driven pressure to convert is relieved. We're bound to reach an equilibrium that will include ipv4 for a long time, possibly forever.

The relevant Econ 101 buzzword isn't "supply and demand," it's "agency problem".

Amazon is "tanking sales" unilaterally, while the supplier manages stock on assumptions of higher sales at the regular, lower price point.

http://www.dailymail.co.uk/news/article-4042194/Facebook-fac...

Microsoft copied the model for operating systems. Token resistance from programmers.

Kite copies the model for programming tools. Too late, programmers.

That seems unlikely. Political and economic leadership throughout the "White West" has been subsidizing and expanding the non-productive underclass for decades.

It isn't easy, but as long as nation states are plausibly more powerful than Google, we—humanity—can hope.

Use antitrust to inhibit moves like the one under discussion.

Use privacy legislation to plug the Google data vacuum nozzle.

Suspend net neutrality in ways calculated to allow ISPs to suck Google dry, while not hurting anybody else too much.

Have you ever observed typical homeopathy users—middle to upper-middle class mothers of young children—in their natural habitat?

I have. They're all "true believers" in that they really think homeopathic remedies are useful, for themselves and their kids. And yet, despite that, they also exhibit a well developed instinct on when not to rely on homeopathy and send themselves or the child off to a "real" medical practitioner. Strange, isn't it?

It ceases to be inexplicably strange if you think about their shared belief in homeopathy as a socially evolved strategy about how to keep themselves and (more crucially) their children away from doctors in those plentiful cases of minor sniffies where a doctor is overkill and actually more likely to do harm than do any better than "doing nothing".

The sad thing is that society doesn't allow a mother to just "do nothing". Where there's no accepted alternative, she "must" visit a doctor, lest she be accused of neglecting her duty to care for her children.

That's why it seems that some parts of society—and not the stereotypically "stupid" ones at all—have evolved mechanisms that afford them social license to avoid the doctor when the doctor is more likely to do harm than good.

Comments URL: https://news.ycombinator.com/item?id=14782924

Points: 3

# Comments: 0

> publishers have to also be responsible for any ad networks or affiliates they have on their site which could use these methods

That may or may not be turn out to be legally anti competitive, but it certainly merits an investigation.

My personal opinion is that it is a clear abuse of G's market dominant position.

EDIT: ...because the policy punishes advertisers use of other advertising providers.

Alas, while Russian (and Chinese) general disinterest in f'ing with you does help, their equally developed general disinterest in your well-being means they might have incentive to sell or trade with entities more... interested.

I have no way of knowing how such changes would affect the wider installed base of FSet. All I can tell you is what I'd prefer myself.

I wouldn't mind, and actually prefer, if the default SEQ would signal a condition on out-of-bounds access (I'd also suspect that not a lot of existing code would break, but there's no way for me to know that.)

On the other hand, I don't think I'd get much besides having to rewrite code out of map lookups signaling a condition. I glossed over my uses of LOOKUP. For most lookups, the case of some element not being present in the map is normal behavior, expected and handled.

For a minority, an element not being present is an error, but for a majority of those, a specific error message is appropriate, so there'd still be explicit checking and no advantage from signaling within LOOKUP.

The smallest group of LOOKUPS expects the lookup to succeed without checking. In all of these cases, the lookup will succeed unless some code is buggy, and in all cases, a bogus NIL would be consumed immediately by a function that would signal a condition on getting a NIL.

So my personal favorite default kind of map would return (VALUES NIL NIL) for lookup failures but would not have a default for purposes of the MAP-UNION etc protocols.

An alternative (or additional) change that would work for me would be an additional optional function parameter to MAP-UNION and friends which, if present, would handle default values.

My only complaint about FSet would be map default values; not necessarily the fact they exist, but (1) when using defaults, that two maps can compare equal even though they have different defaults, and (2) when not using defaults, the way they nevertheless intrude upon the map-union protocol, necessitating handling of otherwise unused default values (usually NIL).

But I love FSet when using CL. Thank you for writing and publishing it!

Agreed on JSON, though.