madarcho

My big issue with the M1 generation is the lack of more E-cores, which get assigned a lot of the OS background tasks. When working at the top of the RAM limit, I'd notice issues around lag to the point that I started looking at CPU stats and found those two measly e-cores completely maxed out for hours on end. Occasionally a crash, though that could be RAM related rather than CPU.

A bit of googling around seems to point that architecture as somewhat of a problem for others, and might be why Apple quickly moved to put more e-cores on the later generations.

Something to consider. Never managed to get proper distinct confirmation that this was the problem, but a (corporate) laptop upgrade did get me out of this pickle.

If SynthID is a google technology, then this is likely just us training their ai again, captcha all over again.

CodeQL was a good help on some projects, but more recently, our team has been increasingly frustrated by the thing to the point of turning it off.

The latest drop in the bucket was a comment adding a useless intermediate variable, with the justification being “if you do this, you’ll avoid CodeQL flagging you for the problem”.

Sounds like slight overfitting to the data!

Where is this worry coming from? (I'm curious, not shutting it down)

I might be biased from having worked with production F#, but it feels more like functional is making its way into C#, as the general industry sees value in functional principles. So F# feels like its more here to stay?

The task sounds similar to descriptions in the API space. People figured LLMs would be awesome at annotating API specs with descriptions that are so often missing. Truth is, everyone is realising it’s a bit the opposite: the LLMs are “holding it wrong”, making a best guess at what the interfaces do without slightly deeper analysis. So instead, you want humans writing good descriptions specifically so the LLM can make good choices as to how to piece things together.

It’s possible you could set it off on the labelling task, but anecdotally in my experience it will fail when you need to look a couple levels deep into the code to see how functions play with each other. And again, imo, the big risk is getting a label that _looks_ right, but is actually pretty misleadingly wrong.

From the wording, they are comparing against all electric vehicles, no specific model year, called to a routine inspection (~MOT).

There is a small note explaining that the Model 3 was introduced in Denmark in 2019 (MY 2020), and therefore 2024 is the first time the M3 has been called to the routine inspection (periodiske bilsyn), hence the specific focus on that model year for this article.

A pleasant surprise seeing an Alastair Donaldson supported paper. What I liked most at Imperial was the amount of professors pushing for things that sat between the fully theoretical world, and the more real engineering world. From a first quick skim this paper seems to hit that right on the head. I've been wanting to see how I could introduce more of the fun of formal verification into my job, so I'll be digging deep into this one for some inspiration.

Well worth a quick trip to the source to see how it's implemented. After all, how would the author get around to packaging 4B if statements, like the OP?

Almost identical pathway here, except with some Spybotics thrown in around the same time as Bionicle. I sometimes wish Mindstorms had that level of world building...

At Unity, Joachim Ante always stayed very close to the underlying engine and its tech, rather than the broader market strategies and moves. Of course, every situation is unique and difficult to compare 1:1.

And we don't necessarily need to step out of the western world to see it. I still remember Authorized Retailers in France before the expansion of Apple stores beyond the US. In Denmark, there is still exclusively these "Premium Authorized Resellers".

Redistribution of taxes, from areas of high densities to lower density prefectures.

Our attention spans have been ruined by the modern age of the internet! If an audience needs to hold a train of thought for more than three minutes, they're gone. Surprise, anecdotes, humor, problem statements, etc... are great tools that stoke the fire of focus.

Another issue is the amount of attention you get to work with. Each surprise moment spurs an increased attention which decays. So, one introduction to the problem is not enough, you have to break things down! Introduce a complication on the original problem, then immediately fix that.

To each their own, but thinking with this pattern for my talks has worked really well for me. Even for mixed audiences (engineers + PMs + management), everyone gets something out of it, and finds their own questions to ask as well. Makes it easier for them to connect it all to their own problems as well.

I imagine a branding change will be in order before actually delivering anything to users?

While I could believe in the artist and their history of fighting off legal challenges, I am sceptical around the ability to (re)build even one of the mentioned tools for the budget. Adobe has an immense moat (hence its complete gall around subscription pricing) for a reason. Otherwise everyone would just be using GIMP.

Exactly the same boat. About to switch to a C# role, so not exactly a world of difference, but I am going to miss F#. I can't help but feel that the success of our small team is majorly down to F# and the traps it helps you avoid.