This is one of the big things I miss from my Pixel 5a; it was so nice to be able to unlock the phone and pull down the notifications bar with one hand. There's a lot I like about the Pixel 8 Pro I replaced it with, but that's one thing I miss.
Interesting! I got no citation/link until I clicked the "Double-Check Response" button, it just replied "The young whale that hung out in Pillar Point Harbor was named Teresa T."
One of the drafts had a little more: "Teresa T is the name of the young humpback whale that was spotted in Pillar Point Harbor. She made headlines in September 2024 when she was seen swimming near the shore, drawing crowds and causing excitement among local residents."
I want to echo the recommendation of Andrej Kaparthy's YouTube channel.
Before I started watching his videos, I thought that understanding how gradient descent actually worked and what autograd actually does under the hood was unimportant - after all, I can get a working network by just slapping together some layers and letting my ML framework of choice handle the rest (and, to the credit of modern frameworks, you can get impressively far with that assumption). Andrej's Micrograd video was what changed my mind - understanding the basics of how gradients are calculated and how they flow has made everything make so much more sense.
If the classes at my university had been as good as what that man publishes on his YouTube channel for free, I would've actually finished my degree instead of dropping out.
I played around with Plane locally a little bit about a month ago - I think it's really promising! I wish the documentation was a little better, though; I had to dig around through the source code to figure out how to get the OpenAI/GPT-powered features to work locally. I also wish it supported the gpt-3.5-turbo model instead of relying on the InstructGPT models (like text-davinci-003) for those features (while this isn't exactly a "chat" use-case, I think the chat model would still do a good job, and the 1/10 token cost would be nice).
I'm planning to set up a Plane instance for my friend group as soon as it supports OpenID Connect (SAML would work as well, but I imagine OIDC is coming first, since it's a lot more sane). We have some small projects we maintain, and we desperately need a nice issue tracking tool like this.
Unless I'm misunderstanding, this isn't bricking the device. The driver is refusing to allow it to work, sure, but it doesn't damage the chip itself in any way. The reason the FTDI incident back in 2014 blew up was because the FTDI driver didn't just refuse to work - it reprogrammed the USB PID on counterfeit/cloned chips to 0, which actually prevented them from working on any host (looking back at articles from that time, it looks like you could fix it by downloading the FT32 config tool from FTDI, but the important point is that the driver was effectively damaging the chips).
I really don't see the issue with drivers developed by a hardware company to support their hardware refusing to work with other hardware. I recognize that it creates problems for innocent end users when they do it, but Prolific just doesn't have any obligations to the end-users of other manufacturers' chips. Refusing to operate (rather than reprogramming the chips like FTDI's solution did) seems like a completely reasonable path to me.
The problem is that you have no way of knowing that you are buying a fake device.
If you run the risk of buying a fake and having it not work then why buy that brand? Buy one that will just work and no risk of bricked fakes.
Prolific are harming their brand by doing this.
I will now be on alert to avoid their products. Not because I take moral issue with them not allowing me to use fakes, but because I risk getting a non-functional device.
Yet if Prolific support the fakes, they end up wasting time and money trying to provide tech support to people experiencing issues with fakes, or having hostile customers trying to get refunds on fakes from Prolific.
The better option is to find ways to ensure you are buying legitimate items, such as avoiding Amazon, eBay, AliBaba, etc.
> The driver is refusing to allow it to work, sure, but it doesn't damage the chip itself in any way
That's kind of immaterial, isn't it? Like most end users won't know how to roll back a driver in the device manager, and without that knowledge their device is as useful to them as one which was actually bricked.
> Prolific just doesn't have any obligations to the end-users of other manufacturers' chips
To me, this would excuse a change that was actually somehow beneficial for their own chips and just happened to break clones, but it doesn't excuse a change that does nothing for their own chips and breaks clones on purpose.
It is beneficial for their chips: the driver will work exactly as advertised and tested. The drivers do not break clones on purpose, the drivers simply don’t enable clones to work.
Write your own driver if you want to use the clones. It is not Prolific’s job to support hardware they didn’t design, build and test.
Even more importantly it is not Prolific’s job to support competitors who are not going to respect Prolific’s IP.
But the driver doesn't work any differently for their own chips than the old one did. And this change was definitely, unambiguously, breaking clones on purpose.
For all we know, the new driver could have been a rewrite from scratch (say to support new products that run at higher speeds than the older driver could support), and the new driver never worked with this particular clone to begin with.
Keep in mind that the driver developer may not even be in possession of a clone of this type. Clones see new versions over time just like any other product, the only thing is that since they don't advertise their true version, it's impossible to practically support them.
The new driver detects clones, puts "THIS IS NOT PROLIFIC PL2303. PLEASE CONTACT YOUR SUPPLIER." in Device Manager, and refuses to work. What sequence of events do you see that would have led to that string existing, let alone all of that happening, unintentionally?
What I'm saying is that just "don't write code to try to detect clones, and treat every chip the same as you're currently treating official ones" would have been sufficient to make it work, and they intentionally did extra work and wrote extra code to make it not work on clones.
Again, you do not actually know that. If you read what I wrote earlier, then you would understand that there are plausible scenarios where no intentional breakage occurred.
I don't know for sure that it was intentional, but you also don't know for sure that it wasn't. And the existence of the string is quite strong evidence in favor of it being intentional.
As genuine equipment manufacturer, it is better to make sure that equipment that used to work before an update, still does after update is carried on. Reject should only occur when the driver is installed for the first time.
While I think this article is unnecessarily critical of the Azure OMI agent, this is a very "What the heck, Microsoft!?" moment for me. Of all the pieces of Azure infrastructure, the OMI agent is absolutely something I expect to be well-tested and secure.
I recognize that bugs happen, but allowing a remote client to execute commands as root by simply removing the authorization header should have been caught by automated testing.
