Orphis

Google is made of many thousands of individuals. Some experts will be aware of all those, some won't. In my team, many didn't know about those details as they were handled by other builds teams for specific products or entire domains at once.

But since each product in some different domains had to actively enable those optimizations for themselves, they were occasionally forgotten, and I found a few in the app I worked for (but not directly on).

Which app are you using?

It's not that relevant for video conferencing, most apps are still either doing H264, VP8 or VP9 and jumping to AV1 directly.

And for video streaming, AV1 is becoming increasingly used on Youtube and Netflix for example ( https://aomedia.org/av1-adoption-showcase/netflix-story/ )/.

It is used a lot more for people who don't have to worry too much about licensing at scale, such as pirate content or local streaming (quite often backed by an OS wide license). Doing a quick search on various pirate content search engine, I can see a lot of AV1 content now, so it'll eventually get more popular!

But it doesn't really apply when big entities with a lot of money are making the video conferencing services that would be using paid codecs. Then the consortiums have clear targets to request licenses to be paid.

They were still using H264 last time I checked, so it's irrelevant to them.

HEVC is far from being the most popular codec on the planet in the context of video conferencing. Most implementations are using WebRTC and as it is unevenly supported and AV1 support is becoming more prominent and stable, most implementations are going from H264/VP8 -> VP9 -> AV1 and skip HEVC entirely.

Each new codec to support is adding a lot of complexity to the stack (negotiation issues, SFU implementation, quality tuning, dealing with non conformant implementations...), so it's never quite as easy as toggling a switch to enable them.

But it is still more performant to do so in general. There are more image corrections of great quality happening than just background removal nowadays, like lighting improvements or sometimes upscaling, and you wouldn't want to do all that on the CPU.

But also, HW encoding of some codecs is not always of great quality and doesn't support the advanced features required for RTC, so the CPU encoding code-path is sometimes even forced! While it doesn't necessarily apply to HEVC as you'd need a license for it (and almost all apps rely on the system having one), it's happening for VP9 or AV1 occasionally more frequently.

Have you read the rationale about CPS? It gives clear examples as to why it doesn't work. You need to parse the files and then parse all the compiler and linker arguments in order to understand what to do with those to properly consume them.

What do you do if you use a compiler or linker that doesn't use the same command line parameters as they are written in the pc file? What do you do when different packages you depend on have conflicting options, for example one depending against different C or C++ language versions?

It's fine in a limited and closed environment, it does not work for proper distribution, and your Bazel rules prove it as it is not working in all environments clearly. It does not work with MSVC style flags, or handles include files well (hh, hxx...). Not saying it can't be fixed, but that's just a very limited integration, which proves the point of having a better format for tool consumption.

And you're not the only one who has worked in a FAANG company around and dealt with large and complex build graphs. But for the most part, FAANGs don't all care about consuming pkg-config files, most will just rewrite the build files for Blaze / Bazel (or Buck2 from what I've heard). Very few people want to consume binary archives as you can't rebuild with the new flavor of the week toolchain and use new compiler optimizations, or proper LTO etc.

pkg-config works great in limited scenarios. If you try to do anything more complex, you'll probably run into some complex issues that require modifying the supplied .pc files from your vendor.

There's is a new standard that is being developed by some industry experts that is aiming to address this called CPS. You can read the documentation on the website: https://cps-org.github.io/cps/ . There's a section with some examples as to why they are trying to fix and how.

It's just a way to ensure you open the desired context on a local Discord instance, not any instance that might be logged in to your account. I have a few personal computers logged in on Discord on the same account that could be active at the same time for example.

I have this laptop and I've charged it with USB-C PD at 90W on multiple occasions. What chargers have you tried?

> Additionally, how do you avoid doing pointless builds when new features are pushed? I can only imagine what the `.github` folder in a monorepo looks like.

It's simple, with proper tooling, you know exactly the dependencies, so you know which test depend on the affected files and can run those tests, the rest shouldn't be impacted. And that tooling exists. It's not the one you may be using, but it exists, and not just in FAANG.

It would help to have quality implementations of the full SCTP specs first.

Do you really think the hardware costs THAT much too?

Users are already paying a premium for the privilege of buying an iOS device. And Apple knows that usually it will add some pressure on friends and family to have devices in the same family. Everything related to the app store is already paid for, the bandwidth is cheap, maintaining the service is cheap enough and covered by the device premium AND the developer subscription.

Whether the apps are free or paid for (with a big cut for Apple), the company is already making money. The tax on top of everything is just a way to make a lot of money and favor Apple services when compared to competitors in the same segment.

While PPPoE worked on WinXP, driver support when transitioning to XP was quite a big issue for some. I still remember hacking the inf files to get my modem work on it as an early adopter.

And it's not even dummy data, I was able to look up relatives on it :o

Your body is undoing the vaccine just fine. It's just ARN, it's discarded after a while. Didn't you learn that in your bio classes or did you think it would never be useful? The rest is just practice for that precious immune system. What's wrong about it? Don't you trust it to do the right thing?

I personally don't because I know about autoimmune diseases, but hey, you seem to be of that "crowd" who only talks in quotes because they don't understand much.

If some group of the population is responsible for 85 to 90% of the spread of a disease, then they are directly harming also all the other people who can't be vaccinated for health reasons, they are helping the virus spread and mutate more often to promote new variants that the vaccinated people might not be resistant to, and they thus are the main reason why we still need to have measures in most countries to limit the spread.

If you're not seriously doing your part, then you are actively supporting the virus and working against all the rest of the population that is either unable to get critical care or just tirelessly working in the healthcare sector treating all those avoidable critical patients.

Why? Seatbelts greatly reduce deadly harm for people in the cars and outside of it.

There are many occurrences where someone died because the body of a person in a crash who wasn't wearing a seatbelt just crashed into them.

You can always lose your license in some places if you are not wearing a seatbelt repeatedly.

Remember that a seatbelt also prevents your body from being a projectile that would be launched against other people in an accident, you're not just a danger to yourself when you don't wear one.

Horrible logic. Seatbelts are in the same position. They are mandatory and greatly reduce harm done in an accident. Same thing for the vaccines, you won't die and won't likely be using an ICU bed that other patients need.

Go spread your FUD elsewhere.

At the same time, a friend who interviewed there got told "You need to work hard and probably on evenings and weekends too". Not a big selling point in Sweden where work / life balance is important (especially to those having or wanting a family).

At the beginning of the pandemic, my team worked on optimizations as priority number 1 as we got a lot of new users with terrible configurations who wanted to do a lot more that what ever intended for that same hardware.

I managed to find a crappy laptop to do some testing and work on optimizations, and it wasn't pretty. No development tool would work on it. My recommendation is thus: aim low, but not the lowest. You'll still be able to measure impact of your changes, and you'll be able to collect some data and other measurements about what is slow.

Use websites like JSFiddle & co is probably the way to go.

> How could we possibly know?

They communicated about it. What else do you want?

> True but the nature of the project and the potential dangers of the project materials also matter.

What are you trying to say? They found a problem, used the protocols they had in place to stop the reactors and they'll take care of it. Looks like they knew the nature of the project and potential dangers and had an appropriate response.

> or anything

There are no reports for leaks I could find, so while you can point at other bad actors in the field, why don't you celebrate the little wins of some company being transparent enough for once?

The upside is they found it. They didn't try to cover it up, it didn't blow up or anything. There will be issues in any complex installation even with the best of planning, what matters is how you deal with those.

There are no APIs in WebRTC about remote screen control. You can share a screen, but that's it.

So they are charging people to remove ads so that the content creator doesn't get any ad revenue from their views? So ethical.

> Git is decentralized and fast, and Google famously doesn't use it.

Most (all?) of Google OSS software is hosted on either Gerrit or Github. Git is not used by the "google3" monorepo, but it's used by quite a few major projects.