asuffield

I don't think that's precisely right either. If I've understood the article correctly, she has three options here: sign up to the new agreement and continue receiving revenue from third party uploads that ContentID matches to her content, stop receiving third-party revenue and leave all third party videos up, or stop receiving the revenue and take all third party videos down.

I'm not sure this would even stop her from getting ad revenue from videos that she uploads herself (the article doesn't discuss this). ContentID accounts are about getting revenue from things other people upload that include your content.

No, that's not right. She can still publish her music on youtube either way. This is about signing up to the "monetisation" option where she can take some of the money from any third party video that ContentID says includes her content. She's currently using that service, and continuing to use it apparently requires signing up to the new agreement.

I'm not completely clear on this part, but I think she can still get ad revenue from videos that she uploads herself. The article is definitely talking about third party video uploads.

It seems fairly clear to me from the article that this is entirely her choice already. She has three options: sign the new agreement and continue receiving cash for videos including her content, drop out of the agreement and stop receiving cash but leave the videos up, or drop out of the agreement and take all the videos down. She has full control over this.

Solar orbit probes don't count - that's Earth orbit plus a small impulse and a battery. All the hard problems are in mining, manufacturing, and life support - the things the grandparent post was talking about.

Although in this instance, that probe is destined for L1, which is still in Earth orbit. (The Lagrange points are where you are simultaneously in orbit around two bodies - Earth and the sun, here)

SpaceX is all about getting into Earth orbit. It has no capacity or projects to go beyond there at present. Elon Musk has expressed a desire to do such things, but the company is not yet engaged with them. Doing so would likely involve fresh investment (for much larger amounts of money) and revaluation.

Earth orbit is hard in terms of energy costs, but relatively easy in other terms: you don't need to solve the long-term independent life support problem, manufacture things off-planet, or figure out how to do supply lines in space.

ISPs who routinely intercept all DNS traffic and rewrite some of the records.

I have had this exact conversation at various past employers, usually when they started talking about "big data" and hadoop/friends:

"How much data do you expect to have?"

"We don't know, but we want it to scale up to be able to cover the whole market."

"Okay, so let's make some massive overestimates about the size of the market and scope of the problem... and that works out to about 100Mb/sec. That's about the speed at which you can write data to two hard drives. This is small data even in the most absurdly extreme scaling that I can think of. Use postgres."

Even experienced people do not have meaningful intuitions about what things are big or small on modern hardware. Always work out the actual numbers. If you don't know what they are then work out an upper bound. Write all these numbers down and compare them to your measured growth rates. Make your plans based on data. Anything that you've read about in the news is rare or it wouldn't be news, so it is unlikely to be relevant to your problem space.

Neither of the above. It's no secret what RMS is doing here, and he's fully aware of the context and way in which he is perceived. Some people like to think that he doesn't care, and they have it almost exactly backwards.

The most extreme person on any issue is always ridiculed and disregarded by a large chunk of any community, regardless of whether this is correct or not. People like middle things. RMS's objective is to be the most extreme person, and to drag that position so far over that no other free software effort can be ridiculed or ignored in this fashion.

You haven't chosen to be the middle ground here. RMS has chosen to make you the middle ground, because that's where he wanted it to be, so he hiked all the way over there to plant his flag in order to move the middle. A few decades later, it looks like that worked.

Invalid takedowns are perjury and are subject to criminal penalties to a maximum of five years in jail.

For some reason, the US prosecutors don't seem to be enforcing it.

> A lot of that data (or similar-enough data when measured in e.g. how much it benefits sales or makes marketing cheaper) can probably be found elsewhere.

If you can find equivalent data somewhere else, you should go build a company around this. People built their products this way because it works. If you have a better idea then you should make it happen.

All the marketing people that I've worked with have used it to do things that you could never do before. Tracking the path people take through your website, which pages they land on, what they spend time reading and what they click through, who comes back tomorrow to buy something - it shows you what works and what doesn't on a level you can't otherwise get. Mapping that onto market segments lets you further narrow this down to just work on the things that are important to the people who buy your product, when most visitors to your site are random click-through traffic that will never buy anything, and feeds back useful information to your product design process.

The degree of focus that this permits is how startups and small companies can find and target their market quickly, where a large company could just market to everybody and see who responds. It's hard to tell how much of the tech startup boom has been driven by this, but after working for and with a few of them, third party analytics is critical because you usually don't have the time or money to find your market without it. Before we had analytics the strategy was "make a lucky guess and verify it before you run out of money". Now the default strategy is "measure who is interested and go directly to them".

I'll accept that large, successful companies don't really get much out of this sort of thing - they already know who buys their product, and have the scale and resources to target everybody. They probably do use analytics just because it's there, and not because they need to.

> Now that they call it "analytics" or "big data" everyone seems cool with it.

It generates massive value that everybody benefits from. People appreciate that.

I don't think there is a particular reason why OO became popular here. There are several ways to do it, the choice between them is fairly close to arbitrary, and one of them became popular.

While I'm no fan of OO as a dogmatic solution to every problem, the differences between it and any other reasonable approach are small for most problems, compared to the complexity of solving the problem itself.

The thing you should keep in mind about stock market commentators, amateur or professional, is:

"If this person actually knew what they were talking about, they would be investing and making a fortune, not telling me about it"

It doesn't matter how smart they are, how many awards they've won, or how successful they've been in business. If they're making a public post about it, it's because they don't really know anything. If they knew, they would keep it quiet and invest.

Linux does this, as does basically every other modern OS.

Pick a random large process on a linux host - like your web browser. cat /proc/$pid/status.

VmExe is the size of the mapped executable; VmLib is the size of all the other mapped libraries and executable pages. Add those two numbers together to find the size of all the executable code mapped into this binary.

VmRSS is the amount of physical memory that the process is currently using. You'll find that this is a lot smaller than the code mapped into the binary. That's because the kernel hasn't loaded any of that into physical memory.

> For example, one of Glenn's earlier protocols kept a maximum of 32 previous message IDs, and operated at a rate of less than 30 UDP packets per second. Unacknowledged mandatory messages were given up on after 1 second of loss.

That seems far more reasonable than what is described in this article. The protocol described in this article has terrible worst-case behaviour and should not be used.

> I have good news for you. We game designers design these protocols to have a (low) maximum rate and a (low) maximum fixed length

That doesn't help at all. You can pick any arbitrarily large or small per-stream data rate - it makes no different to the outcome. Let's suppose the arbitrary internet link under consideration has a capacity of X bits/sec, and your per-stream data rate is D bits/sec under zero packet loss. The number of users that this link can support is X/D. As the number of users approaches X/D, packet loss will begin to occur due to congestion. Suddenly this protocol causes the per-stream data rate to increase towards 120D. This means that X/D users are each sending 120D bits/sec towards the link, for a total of 120*X bits/sec.

Now, recall that X is the capacity of the link, so we have just flooded it with 120 times its capacity. This link is now dropping approximately (1 - 1/119) == 99.2% of packets sent towards it.

Consider: at no point did it matter whether X or D was large or small. The fatal behaviour is that when congestion is detected, the bandwidth usage increases by a significant factor relative to the norm. The factor of this increase will control the steady-state level of packet loss that the protocol converges on, when the network becomes congested.

What's a "TCP truther"? Is it hiding under the bed?

> There you go. Congestion avoidance over UDP. Problem solved.

Yes, that sounds entirely reasonable. Please do this, instead of what is described in the article.

> If it is really desired you could implement throttling according to packet loss, but not in the way that TCP does it - by buffering and waiting - instead you'd just send packets every N frames. You can't do that if you're just using TCP since you don't know when packets are dropped.

It is really desired (and there are a bunch of ways to do it, and plenty of libraries that already implement them). Please, please implement protocols in this way, and not in the way described in the article.

Interesting - I'm not sure that mobile networking really has massively overprovisioned bandwidth, but satellite and radio links might. Can you think of a way to identify these links so that similar techniques can be deployed when they are found?

Then I will make my plea a lot more urgent:

Please do not implement protocols on the internet which respond to congestion by increasing the amount of traffic they send, if there is any chance that they might be used by a large number of people. This is poor internet citizenship and causes real problems. It means your code is a DoS attack against the internet transit links, which can be triggered by anybody capable of inducing low levels of packet loss, and the only effective mechanism to stop it is for ISPs to block the traffic entirely.

Packet loss is how the internet signals that you're sending more bandwidth than it has capacity to forward. Internet protocols need to respond politely to this signal.

You appear to be missing my point, which is that this proposed protocol responds to network congestion by increasing the amount of bandwidth that it uses by a factor of more than 10.

Consider what happens when many clients are using this protocol over a shared transit link and it approaches 80% utilisation, so starts to drop packets at a low rate: all the clients will start batching up larger amounts of history and sending them, which increases the utilisation, which increases the packet loss, which increases the amount of history each client sends... it's a destructive feedback loop that launches a DoS attack against the congested link. The absolute size of each individual client stream is unimportant, as we are merely assuming that the number of clients sharing a link is high enough to congest it. The last-mile user connection is not the worst problem here.

Audio/video streams are a completely different problem - lost data is just lost. This article is discussing a very specific problem where no data loss can be tolerated.

The solution described only works when very high bandwidth is available, because it aggressively sends duplicate copies of data until acked, using on average 2-15x more bandwidth and 120x more bandwidth in the worst case (numbers taken directly from the article).

If you happened to have that kind of spare bandwidth available then yes, this is an excellent solution. When do you have high latency, packet loss, and bandwidth overprovisioned by a factor of 15?

Yeah, but the 100ms/1% version is more or less acceptable - some client-side smoothing would completely conceal those artifacts. It was at 250ms/5% that things really started to fall apart.

I'd say that 1% packet loss is high, and the most likely reason why you'd have packet loss rates that high is because your network link is congested - in which case, sending more packets is the exact opposite of what you want to do.

High latency, high packet loss, spare available bandwidth. I can think of lots of scenarios where you have two out of three of those things. I can't think of any where you get all three, and this idea only seems useful when you have all of them.

The point of this article seems to be that high latency and packet loss combined with extremely high available bandwidth is not a scenario that TCP is optimised to handle.

This would be interesting if I could think of a common scenario on the internet where you get that combination of features.

The first one links to the second; the second is a broken link.

> If you truly believe that learning PHP as a first language is bad for a new programmer, then you shouldn't bite your tongue. But you should be prepared to explain why and present a good alternative and maybe even offer some hands-on instruction.

I routinely recommend python for this, and somewhat more aggressively to people who are making php noises. Not because I'm a massive fan of python, but because it has relatively little syntax and tends to fail in very obvious ways, which is exactly what you want here. On rare occasions I'll offer some direct tuition, but usually I just point people to http://learnpythonthehardway.org/book/ because it really works.

For the most part, it's not all that important where you start - I recommend against people starting out with java or C++, but it's not a tragedy if they do. However, PHP is an exception. I have seen too many new programmers latch on to PHP because "it's easy", and it breaks them. They never manage to learn any other language because "it's too hard to get going, and I can do everything in PHP anyway"; they leave a trail of half-finished projects that hit the 20,000-line wall and couldn't figure out how to get past it. Whenever you try to introduce them to something else they just say "but it's hard, and I don't see why it's useful". You can't teach them how to do software engineering because PHP is too broken and the internet is full of terrible advice about writing PHP code.

Learning PHP first makes it harder to learn your second language, not easier, because of all the bad things you have to unlearn.

Yes, Facebook has a lot of PHP code. That's because they've made a business decision that rewriting it all would cost more than developing highly customised tools to make PHP somewhat manageable and then burning engineering costs on managing it. That cost analysis is very unlikely to apply to anybody else.

I think you're reading too much into this - it sounds like just a bug, which won't affect many people.

Disclaimer: my opinions are my own and not representing those of my employer or co-workers. I have no direct relationship to this project and haven't looked it up internally.

Has it occurred to any of you that we might do these things for sheer fun, because doing that is not only allowed but celebrated?

Print out a recovery code and keep it somewhere safe.

You should be able to remove less secure authentication mechanisms via accounts.google.com, after setting up a security key