We already tried upstream-first development, back in 2010. It was kind of a disaster. The downstream drivers are much more capable than the versions that had been upstreamed, due to the upstream kernel lacking support for the degree of integration between subsystems that Qualcomm's design required. The upstream drivers were functional but compromised in a few ways. When it next came time to do a kernel upgrade, the downstream drivers conflicted with their upstream counterparts. Unofficially, having been in charge of at least one kernel upgrade was sort of a prerequisite for becoming a sub-team lead, and this is partly why. Maybe this time things will be different, between device tree, PSCI, and generally better maturity of ARM support. But, we'll see

Not sure I see the cost argument? I don't think I ever paid more than $15 for a breadboard. An interpreted language on a microcontroller requires too much suspension of disbelief, especially when learning a more embedded-appropriate language requires only marginal additional effort. Trying to run JavaScript on an MCU would be equally silly and for the same reason. Shoehorning python onto an embedded system creates the "illusion" of a simple language, while casually glossing over the _real_ aspects of embedded systems, like resource management, memory allocation, and a limited runtime environment. No amount of window dressing and training wheels will change the fact that programming these systems is fundamentally different from how any sane person normally uses Python. Yes, you could create some 'bridge features' to try to make this easier, but then you end up with a hodgepodge of intermingled concepts that were never meant to go together. This confounds the learning process.

That is a false equivalency. Breadboards are great for both education and prototyping (though primarily the former). But python on a microcontroller is just _silly_ and teaches the wrong thing. If you want to learn to code, great - learn python, on a non-embedded system. If you want to learn embedded systems, great - learn to code, then learn embedded basics. But trying to shoehorn python into an embedded environment is like going out of your way to tie yourself into a pretzel, just so you can do something that doesn't make sense.

Why are we running python on microcontrollers, exactly? It's the wrong thing in production, so why is it the right thing for education? Training upcoming engineers to use the right thing for the job is pretty fundamental; running an interpreted language on bare-metal hardware flies in the face of building that intuition.

I suspect that AI crawlers who have successfully gone undetected are responsible for a decent fraction of this increase.

I was getting pretty sick of having gemini rammed in my face at every corner of Google products. Recently I tried to invoke gemini for some menial email task and was greeted with a paywall. Thank fuck. It's finally starting to blow over

I see a ton of hardware packed in there. An SoC, a bunch of radios, ethernet, wifi, reasonably high-speed blocks like HDMI, etc. The power budget compared to F0 will be very significantly higher. Where will it come from?

I'm curious to know how much $DJT they needed to buy, and at what price, to warrant this kind of exemption? Had to believe this was purely due to industry pressure to explode into a hungry market

On the other hand, the free version gives you more data than Fitbit premium. Garmin DID recently start shilling their premium service but it seems to be focused more on trails and coaching, then raw access to data (for some reason they pay walled real-time workout impact, but the version at the end is free. Server load?)

Can't argue with the price. The current series of venu devices is unbelievably expensive. Some of the others are cheaper but you're still not wrong. As for being developer friendly, Garmin somehow quietly built an entire dev ecosystem, complete with their own sdk, their own simulator, their own LANGUAGE, and so forth. And yes, their tools work on Linux as well. Natively. The simulator uses gtk. What's crazy is it's a dev ecosystem built seemingly from the ground up - they're not using Android Wear but running a completely custom stack. But, this is how they get their battery life to be measured in weeks, not hours.

The Fitbit software ecosystem and posture are just WEIRD. On the one hand, they're trying to position themselves as a clinical-precision health tracking device. On the other hand, their app serves popups for Deepak fucking Chopra and his bullshit. Guys, pick a lane.

But it's the HW reliability that did it for me. Two broken Fitbits (all glitched screens) later, I finally made the jump. Fitbit offered a discount on a replacement, but only one per unit and refused to combine them. They finally caved when I sent them the return receipt held up next to the order confirmation page of a venu2, but, too late.

Had Comcast as an ISP for five years. The only ISP in town, $85/mo for shit service. Moved ten minutes down the street, Comcast is suddenly $55/mo for the same plan, and gasp! there's a competitor in the area. Tried to offer me to relocate my service..... I politely told them to go fuck themselves and they knew there was no point in trying to save the contract.

I'd rather read as well, but I do a fair amount of driving so the audio option becomes appealing. NPR is generally a reasonable option but some of the local radio shows aren't relevant to me, so it can be hit or miss. RadioLab is pretty legit, though sometimes the sound effects and overexplaining can be a bit much. Still, it's pretty alright. I guess I could always just put on the podcast version of the radio shows I already like? I've learned to tune out the call-to-action to do that (or to follow them on all their silly socials, ugh) but maybe this is actually a reasonable idea for once

I tried to get into podcasts, but most of them are just so friggin irritating. They're largely just two or more windbags talking, cracking inside jokes and going off on completely irrelevant personal stories and trying to make you feel like you're there and part of the conversation. Problem is, "trying" is the operative word - none of it is real and the whole thing sits in the uncanny valley of fake authenticity. There was one podcast about the history of a company I worked for - yes, it was remarkably well-researched and largely spot on, but the random tangents and windbaggery made it utterly infuriating. Nobody cares what restaurant you went to yesterday and if it was better than that other place last week - that's not why your audience is here! Okay yes, there may be a few actually decent podcasts that are information-dense and light on filler, but such content is very expensive to produce; the long tail is mostly two randos chit-chatting and I can't relate to anyone who'd want to listen to that.

Yes exactly. It's called the 3M Opticom system for traffic light preemption. A while back, there was a market for homebrew transmitters which quickly became criminalized. Some cities are transitioning to GPS-based preemption (centrally coordinated) but the IR-based system is still very common. It's also used by buses to extend the duration of the green phase (low priority preemption) without changing an existing red, like the high priority signal would.