Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

To head off regulators, Google makes certain words taboo

themarkup.org

Post reply on HN
Print view View original

241–250 of 319 posts

Re: To head off regulators, Google makes certain words taboo

#241

Post by ytdytvhxgydvhh »

monadic2 wrote: post #195
ytdytvhxgydvhh wrote: post #184

Earlier quoted context omitted.

I’m not sure that it’s insane to kill off profitable products. Some folks were upset recently that Honda is discontinuing the Fit subcompact hatchback in the US. That’d be easily understandable if it were an unpopular, unprofitable product. But the Fit was well-loved and dealers struggled to keep them on the lots. So why did Honda kill it? The HR-V subcompact SUV based on the Fit has been produced for the US in the s…

How does that make sense? On paper they just lose the revenue of the Fit without gaining any new revenue elsewhere. That’s just a loss. It takes some magical thinking to argue that these lost customers will move over to the more popular model, a qualitatively different car.

If you’re Honda and you’ve got a factory that can make 100000 cars a year, would you rather make 100000 cars that make $2000 profit? Or 50000 cars that bring $1000 profit and another 50000 cars that bring $2000 profit?

If you’re Google and you can only find N top notch software engineers, do you want to put any of them on marginally profitable projects?

Re: To head off regulators, Google makes certain words taboo

#242

Post by jpxw »

danans wrote: post #238
asdfasgasdgasdg wrote: post #218

Earlier quoted context omitted.

Ugh. I detest that phrase. :( It sounds so corporate.

Doesn't sound corporate to me at all. Corporate to me is things like "increase synergy". Respecting the opportunities available to you by showing respect for your competitors who are just like you at the end of the day seems like a pretty real and relatable recommendation.

If you need to remind yourself that you need to “respect the competition”, you’re probably a monopoly.

Re: To head off regulators, Google makes certain words taboo

#243

Post by josephg »

dragonwriter wrote: post #178
shadowgovt wrote: post #68

Earlier quoted context omitted.

I'm not convinced, though there are, obviously, advantages to RFCs and IETF. The primary disadvantage is speed. A private corporation innovating on its full stack can come up with a faster and more secure HTTP alternative for their use case in the time it takes the RFC process to get up in the morning and find its shoes. Google has a streamed cloud gaming service running in its web browser right now; how long would i…

> A private corporation innovating on its full stack can come up with a faster and more secure HTTP alternative for their use case in the time it takes the RFC process to get up in the morning and find its shoes. But...that's part of standards process. It's quite common for the actors like Google to propose a new/revised standard after implementing it independently SPDY (became HTTP/2), HTTP over QUIC (became HTTP/3)…

Exactly.

I was talking to people at the IETF about this last year. One person said the ideal use of the IETF (and RFC process) is to take situations when multiple companies have solved the same problem. The IETF puts everyone in a room (/mailing list) together and lets us collectively figure out a single interoperable protocol that all the members can implement in order to make their systems compatible.

The golden path isn't "Joe blogs needs a protocol for something so he writes an RFC". Its "Joe need a protocol. He writes his own and iterates on it. Later he meets Sarah and Dave who've all written similar protocols to solve the same problem at their own organizations. Together they approach the IETF and form a working group to discuss a standard."

Reality is usually much more messy than this; but generally the IETF should never be a bottleneck for people who want to write code and try things out. Racing ahead of whats written in RFCs doesn't stand in opposition to the RFC process. The opposite - racing ahead is a necessary part of the process, because we need collective experience in how to solve a problem in order to write good standards.

Re: To head off regulators, Google makes certain words taboo

#244

Post by josephg »

jacquesm wrote: post #209
johannes1234321 wrote: post #187

Earlier quoted context omitted.

There is another downside to IETF/RFC/public standard: it's hard to move forward. My favorite example: e-mail. SMTP and IMAP are old and have so many issues. On the SMTP side it is hard to identify authorized senders, which is a reason for spam, IMAP doesn't really work nice with mobile devices. On the other hand there are messengers like WhatsApp which solves many of those issues and allows adding features (for good…

RFCs don't get changed, they get replaced by new ones. Until we find something that is 'good enough'. SMTP and IMAP are now older than quite a few of HN's readers. They could be replaced by something better, all someone would have to do is design it and put out a new RFC. What is true though is that once a protocol is 'good enough and it gains mass adoption that change is hard but this is more to be blamed on human n…

And this is happening. The JMAP working group at the IETF is writing new RFCs to replace SMTP/IMAP, Caldav, and others with a much cleaner protocol built on top of JSON and HTTP.

Its already in use at Fastmail and a few other places. (The fastmail web client talks JMAP to get your emails from the fastmail servers.)

Specs and more here: https://jmap.io/

Still no sign of adoption by gmail / etc but hopefully we'll see the industry move forward eventually.

Re: To head off regulators, Google makes certain words taboo

#245

Post by joe_the_user »

jacquesm wrote: post #59
shadowgovt wrote: post #14

Earlier quoted context omitted.

It's not even so much about protecting the secret sauce as protecting user data. Every tool interfacing to the Google backend is a potential attack vector. When the time comes that nobody's willing to bear the cost to keep it updated as the core infrastructure changes, the product dies. In a world where Google is split up, that'll still be true; it'll look more like "Google CoreCloud has just changed API foo to prote…

That's why we originally had an IETF and RFC's were publicly commented on and why standards are supposed to be company agnostic. The whole proprietary-APIs-over-HTTP was a giant step back. Before we did that interop between internet based applications was far more common and supported. Now every company treats 'their users' as their own private little walled garden when before 'your users' were not so much cows to mi…

Sure, it would be nice to go back to IETF and RFCs. But it seems like the discussion has wandered far afield from a Google breakup (more standard APIs/protocols may not result from a breakup and may not need a breakup).

And what I hate about Google/Facebook breakup discussions is how they seem driven by a mob of all those having complaints against these tech giants, where the complaints contradict each other (too much censorship, too little censorship, Google too few or too many products, etc) but the likely upshot on success is states gaining more leverage over these companies and using them as even more effective control/propaganda outlets.

Re: To head off regulators, Google makes certain words taboo

#246

Post by hombre_fatal »

owowow wrote: post #114
shadowgovt wrote: post #68

Earlier quoted context omitted.

I'm not convinced, though there are, obviously, advantages to RFCs and IETF. The primary disadvantage is speed. A private corporation innovating on its full stack can come up with a faster and more secure HTTP alternative for their use case in the time it takes the RFC process to get up in the morning and find its shoes. Google has a streamed cloud gaming service running in its web browser right now; how long would i…

OnLive was streaming games years before Google entered the space, there isn't much novelty in what Stadia has done.

The novelty will be if it's profitable / something people want.

Re: To head off regulators, Google makes certain words taboo

#247

Post by acituan »

lrem wrote: post #223
acituan wrote: post #212

Earlier quoted context omitted.

Well the point is there is no “secret sauce infra”, let alone Google specific infra as the OP speculates. If we were to claim timing as a factor, AWS was available since 2006.

You really missed the point. It does not matter if the "secret sauce infra" is better than equivalents. What matters is that the code you have is based on it. And since literally everything is based on Stubby, which has a hard dependency on Borg, once you remove the bits of the backend's code that are secret-sauce-dependent you're left with a Makefile ;) Disclaimer: I work in Google, but the above is easily inferred…

> It does not matter if the "secret sauce infra" is better than equivalents.

That is what the OP suggested.

> What matters is that the code you have is based on it

It is the nature of infrastructure is to be independent from business logic. I’m not saying any migration would be trivial, but it is also not as cost prohibitive as you seem to be arguing for. RPC is a very old and generic concept, so unless reader was depending on Google specific RPC mechanics, the cost of swapping one RPC tech with another is not going to be to the extent of warranting uttering of concepts like anti-trust.

Re: To head off regulators, Google makes certain words taboo

#248

Post by dragonwriter »

tetrometal wrote: post #232
dragonwriter wrote: post #146

Earlier quoted context omitted.

> Capitalism is built around competition and anti-monopoly, philosophically No, it's built around centralization and rent-extracting monopoly power moving from the feudal aristocracy to the mercantile (now “capitalist") class, motivationally and historically. The risible competitive and anti-monopoly argument that bears no resemblance to the facts (anti-monopoly controls were one of the major elements of reactions ag…

Capitalism is property rights and economic freedom. There's nothing inherent to it that requires monopoly. Natural monopolies can occur but are perpetually unstable provided there are no artificial barriers to entry. Of course, those barriers exist (one form is regulatory capture), but they are not capitalistic. Absent those artificial barriers, even natural monopolies must behave over the long term as though competi…

> Capitalism is property rights Capitalism is property rights

Capitalism is a very specific model of property rights and economic freedom as far as consistent with that model, which was designed—incrementally, over a long time—to advance the power interests of a particular clases (mostly not collectively, but as the aggregate of individuals in that class leveraging their growing power to advance their personal interests.)

Confusing it with “property rights and economic freedom” more generally is just as wrong as doing the same with feudalism, which likewise featured a particular model of property rights and economic freedom so far as consistent with that model of property rights.

Re: To head off regulators, Google makes certain words taboo

#249

Post by shadowgovt »

jacquesm wrote: post #236
johncolanduoni wrote: post #221

Earlier quoted context omitted.

Unless your plan is to change human nature, where the “blame” goes is pretty academic. The inertia is still an issue when going the RFC route, and less of an issue when standards are developed first to fill a specific need for an interested party.

The inertia is a good measure for how successful a particular protocol version is. See for instance IPV4 and how hard it is to get rid of it. And that inertia is good , you don't want to rip up your standards every two years.

Every two years, no.

When the standard starts to actively limit further development, though...

https://en.m.wikipedia.org/wiki/IPv4_address_exhaustion

Re: To head off regulators, Google makes certain words taboo

#250

Post by cheerlessbog »

d1zzy wrote: post #168
Afforess wrote: post #8

Google (okay, Alphabet) is the only big tech company that I can imagine would ultimately _benefit_ from an antitrust breakup. Google keeps killing low-to-medium profitable smaller product lines and tools because it can't spin them off successfully. Google can't spin off tools successfully because their internal codebases are deeply reliant on assumptions about Google's infrastructure and Google internal libraries, et…

The engineering effort required to split up a mammoth code base where everything has been written based on those assumptions about the rest of the codebase is making such a split extremely unlikely to succeed. We're not talking about a few millions lines of code, we're talking about billions[1] of lines of code. It would take more than a decade of having thousands of engineers work only on this and not do anything el…

Is this a negative result of mono repo? There’s no natural boundary physics.
Post reply on HN