phh

Yes, France's current situation fucking sucks. However my answer was for this message:

> Right now gas plants are running to stabilize the grid in France...

As far as I know, gas plants have always been used to stabilize grid in France.

Most smartphones do that, it's part of all SoC vendors' base code. However Google Pixels don't do that (which leads to no standard Android API available for that...)

Uh, as far as I know, that's forever been the case? Nuclear is too slow to react to events, so we always need some safety margin that gas can provide?

If there's no gas, most homes can heat with electricity. Turn on your oven, your gaming console, your TV, open your fridge's door, etc. Also as I understand it, it's much easier to do rolling blackouts on electricity than on gas, so gas will be more likely to fail for a long time than electricity.

Most industrial processes can be stopped without endangering people.

Wow, what city? Sounds like that would make for interesting news read

Don't you need a proprietary firebase SDK in your app to use it? Do you know what data are included in the requests? I would argue that anything as simple as IP + UA/OSidentifier can be of interest to Google

I thought it was a bit hyperbolic, but yeah, looking at headers (both userspace and kernel), I can't see anything remotely related to camera. I would have at least expected a "color"space somewhere (colorspace which could have included jpeg/heif/... as format)

> Imagine you work for the customers' support team: you unblock the client, the client is happy, and you also fix the public doc to unblock anyone after you… That’s all great. But at large organizations (namely: Google, Facebook, and LinkedIn) people ask: should we have a CS team at all? Isn’t that objective unscalable and trying to satisfy people a feature we shouldn’t have because every solution should be a product, not a process?

First on the "scalable": CS is most definitely scalable, the question is how much. Without using any tooling whatsoever I dare say it scales in O(N*(log N)^2). I can understand the will to optimize it, and with good tooling, I have no doubt it can become sub-linear, which is more than enough. Anything sub-linear wins money with growth, so no need to "make it a product" (which I read as: Put a team of O(1) to replace those people, but maybe I'm misunderstanding)

Anyway on to my point: Your Google example proves TFA's point: Google having broken CS is one of the major pain point against Google most people here have. Another Google pain point can probably be explained by misuse of KPIs: Google products that keep getting killed, and replaced, again and again.

Even the best people are subject to "the spreadsheet mentality". Even when they are aware of it! My employer's founder bought back the company to stop focusing on the company's share price. Musk would like to take Tesla private. France renationalized EDF which was already >80% own by the state. etc.

Can you share more about your setup? I also have a sdm845 gaming handheld (Ayn Odin, currently running Android), and I was contemplating installing Windows on it to get Steam, but I much prefer your way.

Do you have some clean distro that boots into something usable without mouse/keyboard? Some documentation for first stage boots? Gits?

> 5x overbuild won't be enough, as I mentioned elsewhere at least in TX its not unusual for the wind to be producing at less than 15% of rated capacity. Particularly in the winter/summer when the energy load is at its highest.

Unless TX has a median load factor of 100% (in which case, wow), 5x overbuilding on top of median load factor definitely works in the case you describe.

As far as I know, the typical wind average load factor is 33%. So over-scaling by 5x of that would mean that 7% is still enough to provide. Granted, that's not a very large margin to the 8% you mention, but Europe is bigger than Texas, so it's less likely to have such a low-wind event.

You'll notice that I mentioned over-scaling wind, not solar. I'm not a fan of solar overall, except maybe some clever big projects like using deserts, and for personal self-sufficiency (where people would over-scale a lot).

I don't mind keeping building solar panels, but subsidizing requires proper analysis of the benefits and externalities (notably on the grid) rather than blindly giving money to anyone saying !SOLAR! like we currently do.

Thanks for the article, I didn't know climate models estimated EU will have less wind, I expected we would get more wind.

That being said, the article is pretty low on numbers. The only actual number shown is -32% in UK. Which can totally be overcome by having 5x overproduction in whole of Europe.

Does it? I feel like if we overbuild wind by like a factor of x5 in whole of Europe (on top of the median load factor, not assuming 100% of course), we would pretty much not need coal or gas. x5 ratio is still lower than nuclear reactor budget and time ratios overrun in the last 2 decades.

That being said I'm all for not putting all our eggs in the same basket, and having both nuclear, wind, solar AND coal and gas plants is fine by me (but the plan must say that the coal and gas plants will never be in use, but they are ready "just in case")

> 1. There is no way to remove devices drivers from the Linux kernel. That goal was seen as desirable in terms of improving reliability, how long devices were supported for and the time taken to roll out updates. Upstreaming driver changes was something phone manufacturers just didn't do and didn't want to do. Linux has no stable ABI for device drivers; and

Android's Project Treble was already supposed to (partly) fix that, and it didn't. Partly because of OEMs sure. But, and most importantly, because Google removed the support for versioned RPC merely 3 years after its introduction (audio HAL 2.0 introduced in Android 8, got removed in Android 12, simply reverting the deletion commit is enough to "fix" it).

What does this tell? This tells that Google themselves aren't structurally ready to support hardware for more than 3 years. Why would Fuchsia be any different? In all likelihood, they'll also deprecate versioned ABI every 6 months, and drop old support after 3 years, which will lead to the exact same state.

At this stage, this is a managerial issue, not a technical one anymore. If Google wants to do this (upgrade devices independently from OEMs), they first need to stop obsoleting code every time someone gets a promotion, and they need to actually try what they make, not just do things that are theoretically perfect [1]. (to the best of my knowledge, there is exactly one Google team who managed that, which is androidx/jetpack/android-compat)

> Upstreaming driver changes was something phone manufacturers just didn't do and didn't want to do. Linux has no stable ABI for device drivers;

Chromebooks have most/all drivers upstreamed, and yet they never upgrade their kernels in production.

[1] And I could go on how Project Treble is architecturally beautiful, but is missing few small points that would make it actually usable, which is what my opensource project does, but I feel my message is already too diluted

Except that HarmonyOS (for smartphones) is actually bog standard Linux/Android?

While in this case, they are rewriting the kernel (but I agree that it looks like it'll remain normal Android for the upper layers)

> VoLTE and VoWIFI, for example, are both wrappers over SIP if I'm not mistaken

Not wrappers. VoLTE is literally SIP with extensions. And VoWiFi is literally VoLTE over IPSec/IKE with EAP auth, so SIP over IPSec. Really just bog standard stuffs.

> – pretty complex, but still using modern tech

Not sure about "modern", but yeah pretty much every actor uses SIP one way or another. It does have a few old stuff (one SIP extension of VoLTE is to allow SIP-negotiated IPSec tunnel. For HMAC it supports md5-96 and sha1-96 and that's all.), but nothing that makes you scream of over-complication.

I'm rather ignorant in that domain, so I wonder if some people could enlighten me. What are the AI tasks behind this?

I can identify two steps:

- Identifying an approximate shape of background vs foreground to get something more precise than just a rectangle. What is it called? Just background detection?

- Actually filling-in the holes. I think this is called a diffusion task? Is that correct? ddg-ing around looks like diffusion is the name of the method rather than the actual task, but I can't find the name of the task.

I'm curious at whether some existing open models would be usable on smartphones to make an opensource app (or maybe there are already such apps I'm unaware of)

> By contrast, your extremist proposal of allowing patentholders to block software implementations of international standards unless they are paid, that is clearly absurd, as it imposes a completely unreasonable burden on the open-source maintainers who are the backbone of modern software.

My extremist proposal, where I say in the first line that opensource maintainers should be free of any patent requirement?

I think there is some middle ground to find. As of right now, looking at audio codecs on Play Store, there is some status quo which is IMO good (but it requires to actually be written somewhere, otherwise shit will happen): Opensource applications that are not shipped with devices but are available "on the internet", or some app store aren't threatened by patents holder.

(Source: I'm a contributor of opensource NOVA Video Player, which was previously closed-source Archos Video Player)

As a company, I think that paying for standards is fair, but it must be reasonable. Reasonable implies 1. clear rules which never blocks innovation [1][1b] 2. reasonable fee [2], 3. freedom of using whichever implementation of that standard I want, 4. If fee has been paid on HW, then any SW on that HW is allowed to use that license

[1] Some vendors will sell their licenses exclusively on hardware, so if you sell an app, you're screwed

[1b] Some vendors will require you to make different SKUs whether you enable it or not. What if user need to enable it later?

[2] Sisvel's AV1 license is 15c, which is imo fair for a 200$ HW, but not for a 1$ ad-less video app. That being said, I have no idea how to actually make it fair. (Note that as I understand it, Sisvel's AV1 license is for HW, not SW, no idea how it works for SW)

> [0] For context: The EU competition regulators believe AOM may have bullied people into royalty-free licensing. This could either be read as "Google screwed up their legal research" or the EU deciding that reciprocal royalty-free patent licensing itself needs to die.

Sounds like you're assuming that the issue is with AV1 itself. My personal guess is that the issue is rather that some AOM company could coerce some patent-owner companies into using AV1, and thus "relinquishing their patents".

Stupid obviously unreal example: If Apple require iPhone resellers to display Apple's advertisement from AV1 codec. Then resellers have the choice to either stop selling Apple products, or give their patents for free to AOM. If that was real, it could be considered an abuse of Apple's dominant position.

In the case of the Xbox, you can replace the mainboard with like a rpi and still achieve it quite easily (I'd say budget ~ 100€). That's harder for a smartphone (I'd say budget ~ 2000€). Either way, the budget is still lower than the price of security flaws to circumvent secure boot.

If you can't modify victim's computer itself, just do that on another computer?

The evil maid will need less time to replace the computer with another one that looks alike the original one, than to install a Linux distro

As a French, I've taken French taxi maybe like 20 times in my life (Paris & Rennes), and never had any issue with them (granted it was largely post-Uber, so maybe they improved because of it). I took ubers few times, it didn't feel any better than taxis.

> More nebulous is YouTube profit, which might be as low as zero (I can't find a source).

Ah right sorry, I googled youtube profit, and it returned youtube revenue. I would guess Google doesn't want to even know the profit of youtube, because that would be another anti-trust nail.

> That said, would human content moderation be particularly better? Lots of stuff falls in the gray.

Yeah I agree, that's just back of the napkin computation and it's missing a lot of nuances. Like how can you fact check a video by just looking at it? You can't. This requires more work. But then, you can probably look at videos at x1.5 speed, many videos are probably similar so with proper tooling you can find similarities and at least route it to the same person so they'll have less research to do to validate.

But overall I believe that there are both issues that make it cost more than just that, but also easy optimization wins that make it cost less than that. Either way, I believe that if youtube comes forward saying they spend 2B$/yr human salaries (spending 2B$/yr in training GPT-42 doesn't count) they'll get more respect from their users, even if it's not enough to be prefect.

Quick computation: 500hrs/minute => 262Mhrs/yr, US minimum wage 7.25$/hr, assuming no tool (but no verification), 1x playback rate, 2B$/yr, youtube revenue was reported at 15B$/yr in 2019.

Yes they can afford it.

Well this is already ongoing. In France:

We already have automated (no staff in train) metros (Paris' 14, Paris' 1, soon Paris' 4, Paris' Orlyval, Rennes' a/b just for the ones I've used)

I remember there was a prototype bus (12 person size ~) at La Défense - with a staff always on board, and I see that now there is "EZ10" in Toulouse, but I remember seeing also other lines as well. I'm pretty confident there are many all across the world.

It defaults to JAX. To use torch, add --torch parameter

(I'm not deaf, and barely discuss with hard of hearing people, so I'm likely not relevant)

Main factor should be to ask him, to better understand how he "works around". "Best case comparaison" for video conferencing is IRL meetings. Does he feel "comfortable" with IRL meetings assuming proper lightning and face orientation? If not, then it's likely there is no fancy video conferencing that'll be ok, and just forget about video conferencing.

Assuming he reads lips, better video overall: Give all co-workers better cameras and lighting, check that Microsoft Teams doesn't compress stupidly (if it does, maybe try other systems...), have your coworkers frame the camera properly on their face. Better mics if he can hear a tiny bit.

Write minutes live in a shared document.

Would you be open to AGPLv3? This mandates allowing the user to replace the code with their own, and requires publishing source code to users even if it's "hidden in the cloud". (well IANAL, so don't take my understanding as a fact)

> People have started realizing that when people say "AOSP Android" they actually mean "Google Android" because the discussion is never about how to get rid of google bloat, only how to get rid of manufacturer or telco bloat.

That's definitely your own bubble :-)

I have bubbles where they say "stock android" to mean "AOSP + google apps", I have bubbles where "AOSP" mean "*without* google apps" (notably professionally), and I have bubbles where AOSP just means without major changes to AOSP but doesn't imply anything about whether it's using google apps or not.

Notably, I make an "AOSP" ROM which has three variants, one with Google apps, one with microg, one with nothing, and sure I have more users using the Google apps one, but that's maybe 2/3 for google apps, 1/3 for non-google apps.

> Meanwhile I actually think that the OEMs have driven innovation and usability in the Android smartphone space as much as or more so than Google. Sure, some of the UI was over the top but it was a learning experience for consumers as well as for manufacturers.

Yeah that's a pretty hard compromise to make. Nowadays, the compromise is moving hard towards "use Google-provided UX with very minimal changes", which imo reduces innovation, but most devices have pretty close UX from each other (I have a friend who moved from a OnePlus 5 Android 10 to a Samsung Galaxy A53 running Anddroid 12, the vast majority of their annoyances are because of Android 10 => Android 12 changes). A decade ago, going from one OEM to another you had very different UX (and very slow OEM UX...)