Because firing people in Germany is a multi-year process that requires (among many other things) paying for a complete training course in all job-relevant skills under the assumption that any incompetence is caused by insufficient training.

It's not an assumption- it's a factual statement about how wordle works

I can confirm that it took way longer than that on actual contemporary hardware.

I think you're 180° backwards on that.

How many alternative platforms are there really going to be that can afford to develope and operate the legally-mandated age-detection ML-models?

Especially after the bureaucrats see that the law isn't working and start looking for scapegoats without massive lawyer teams to make an example of

Why would they do that? There are plenty of platforms that simply won't care, and there's stuff like Mastodon et al.

The law tends to be pretty good at caring about you when you don't care about it.

+1

The industry has a solution for the exact problem the urllib is having (semver). Urllib just actively refuses to use it.

I think you may not be familiar with how embedded development works.

Most teams who write code for embedded devices (especially the weird devices at issue here) don't have the hardware knowledge, time, or contractual ability to write their own compiler backend. They're almost always stuck with the compiler the manufacturer decided to give them.

You're right. But I'm also surprised any device manufacturer would think it's a better use of their time to ship a bespoke C compiler rather than an LLVM backend that would allow a lot more languages to be built against their ISA, making it more valuable.

But ya, I believe this project exists for a meaningful purpose, I'm just surprised.

> But I'm also surprised any device manufacturer would think it's a better use of their time to ship a bespoke C compiler rather than an LLVM backend that would allow a lot more languages to be built against their ISA, making it more valuable.

They aren't usually building a compiler from scratch; they modify their existing compiler[1] for their new hardware, which is fractions of effort required compared to building a new compiler or modifying the LLVM backend.

Unless it's a completely new ISA, they'll spend an hour or less just adding in the new emit code for only the changes in the ISA.

----------------------------------

[1] Usually just the previous gcc that they used, which is why in 2022 I was working on brand new devices that came with a customised gcc 4.something

I think the approach would not be to alter the manufacturer's compiler directly, but to run your Rust code through a separate Rust-to-C compiler then feed that output into the compiler the manufacturer gave you.

Why, of all parts on a phone, would you expect the battery to be the one that's already good enough that it should never need to be upgraded?

"Battery capacity" is like the one thing phone manufacturers still try to improve.

The interfaces and the external dimensions can remain the same even as the internals change though, right? And you can have more or fewer cells. The cells don't have to be cylinders, either. They can be flat.

They are usually shaped to fit in exactly the space available to maximize capacity. Standard cell sizes wastes space.

Besides it's pretty easy to get custom battery pouches made.

Who will make these custom battery pouches for old phones though? Think my old Poco x3 pro, not the iPhone 17. I am sure there are tons of people willing to make batteries for the iPhone 17 but I feel like the interest wanes as the phone gets older?

For older phones, the batteries we buy are likely also old stock left over if we can find some in stock anyway, right?

But if % 2 && % 3 is better, then isn't there still a missed optimization in this example?

Let's throw this into godbolt: https://clang.godbolt.org/z/qW3qx13qT

    is_divisible_by_6(int):
        test    dil, 1
        jne     .LBB0_1
        imul    eax, edi, -1431655765
        add     eax, 715827882
        cmp     eax, 1431655765
        setb    al
        ret
    .LBB0_1:
        xor     eax, eax
        ret

    is_divisible_by_6_optimal(int):
        imul    eax, edi, -1431655765
        add     eax, 715827882
        ror     eax
        cmp     eax, 715827883
        setb    al
        ret

By themselves, the mod 6 and mod 3 operations are almost identical -- in both cases the compiler used the reciprocal trick to transform the modulo into an imul+add+cmp, the only practical difference being that the %6 has one extra bit shift.

But note the branch in the first function! The original code uses the && operator, which is short-circuiting -- so from the compiler's perspective, perhaps the programmer expects that x % 2 will usually be false, and so we can skip the expensive 3 most of the time. The "suboptimal" version is potentially quite a bit faster in the best case, but also potentially quite a bit slower in the worst case (since that branch could be mispredicted). There's not really a way for the compiler to know which version is "better" without more context, so deferring to "what the programmer wrote" makes sense.

That being said, I don't know that this is really a case of "the compiler knows best" rather than just not having that kind of optimization implemented. If we write 'x % 6 && x % 3', the compiler pointlessly generates both operations. And GCC generates branchless code for 'is_divisible_by_6', which is just worse than 'is_divisible_by_6_optimal' in all cases.

I also tried this

  bool is_divisible_by_15(int x) {
      return x % 3 == 0 && x % 5 == 0;
  }

  bool is_divisible_by_15_optimal(int x) {
      return x % 15 == 0;
  }

is_divisible_by_15 still has a branch, while is_divisible_by_15_optimal does not

  is_divisible_by_15(int):
        imul    eax, edi, -1431655765
        add     eax, 715827882
        cmp     eax, 1431655764
        jbe     .LBB0_2
        xor     eax, eax
        ret
  .LBB0_2:
        imul    eax, edi, -858993459
        add     eax, 429496729
        cmp     eax, 858993459
        setb    al
        ret

  is_divisible_by_15_optimal(int):
        imul    eax, edi, -286331153
        add     eax, 143165576
        cmp     eax, 286331153
        setb    al
        ret

I don't quite get your objection here. Is it to the fact that browsers are commonly used to show video, or the fact that smoothly showing video requires changing certain power saving settings?

My objection is that merely visiting a website can invoke all kinds of unexpected things happening on my computer. As a web browser user, I don’t expect it to be modifying how timers work on my system, or accessing peripherals and radios, or programming my GPU or the memory of other processes, or my location, or writing to my filesystem, or basically anything else other than what is needed to draw text and images onto a browser window.

I still don't get your objection. Changing system timer settings is required to show HD videos on a browser window in a smooth way.

Are you objecting to the fact that that's the case or that browser windows are being used to show HD videos?

Yeah, that claim killed all credibility of the author for me. I firmly believe that if making your point requires you to invent some statistics that clearly don't pass the smell test, it's time to accept that your point may be wrong.