Copyright rules allow FB to make lots of money, without breaking the rules.

However the only reason they can make any money is that they have readers. They have a monopoly on eyeballs, which they rent out to publishers.

That used to be against the rules: less so these days (:-()

Andy Stone "added that the proposal fails to recognize that publishers and broadcasters put their content on Facebook "because it benefits their bottom line -- not the other way around."

That's trivially true, but doesn't speak to the argument of whether Facebook should pay publishers. FB is better at making money than the publisher, from the publisher's work. Publishers (such as myself: I have a blog) post on FB because that's the only way to get any readers at all. FB gets me readers, and for the privilege, takes ten to 100 times what I get. All while playing by the rules, posting links and small snippits, something they're legally allowed to do.

FB isn't breaking the copyright rules: no-one says they are. They're breaking the monopoly rules.

So the professional sophists at FB say true things about copyright, and keep the conversation about copyright. Their actual advantage is called "monopoly rents", and that's something they're never going to mention. And if you mention it? They'll say "copyright", "copyright", "copyright" (;-))

We don't want you connecting your devices to our telephone lines, you could break them.Tell us what you want and we'll sell it to you.

Oh, a MOdulator-DEModulator? No, we don't think you should have MODEMs. You might send computer signals over our lines...

See, for example https://cassels.com/insights/s...

A counterfeiter fled Canada, a Canadian court ordered Google to stop linking to the counterfeit products. Google asked a US court to block the court order worldwide, and was laughed at. Google can only show links to the counterfeit product in the US, where the company is protected by US law, but nowhere else in the world.

If you have a fork in the road, you gave to take one or the other. If, on the other hand, you have something that can change, you can start down one path, find it isn't viable, and change direction.

Multics (and Solaris, and Linux glibc) understood API mutation[1]. Go and Sun OPCOM understood rewriting source code to support mutation in formal grammars.

What we have to do is put these and Mr Carmi's proposal together, and create a path from Go 1.0 to a next-generation language. Call it go 2, and the next one Go 3, until we get to a state where we don't feel the need to do fork-sized changes any more. Then we can have Go 4.1.3, 4.2 and so on.

--dave
[1. I was Paul's editor]

The lead author, Venkat Arun, noted that fair queuing (FQ) not congestion control is what one needs. And in the Linux kernel, that's part of both fq-codel and CAKE

From the bloat list: https://lists.bufferbloat.net/... Starvation in e2e congestion control

Hi Dave,

Yes definitely, when fair-queuing is present, the onus is no longer on the congestion control algorithm to ensure fairness. In fact, if buffer-sharing is implemented correctly, FQ can even stand against adversarial congestion control algorithms. We have good reason to believe that end-to-end congestion control algorithms can provably work (i.e. achieve high utilization, bounded delay and fairness) in the presence of FQ.

Cheers,
Venkat

I expected better from the IEEE, who previously avoided writing click-bait articles...

By the way, the Dave he's writing to is Dave Taht, a /. member and an expert on network performance

"Public mischief", from the Criminal Code of Canada, RSC 1985, c C-46,

Canadian judges are polite... while they throw your ass in jail.

Libraries buy and lend such books all the time, we're merely very used to it.

Initially, there was considerable push-back from publishers in England when private individuals donated their libraries to "book lending societies", now called "public libraries". There's quite a history there: for example, bookplates came into much wider use (https://westphaliapress.org/2018/02/16/the-rise-of-the-book-plate/)

I happen to use backintime, https://github.com/bit-team/ba..., which at one time also suffered from an overloaded maintainer, an also used rsync for (non-snapshot) backups.

I wonder if the authors know about each other?