jmole

This is not the first time they've done this either. They seem to go back and forth on this decision.

This seems like a bad decision to me that will ultimately harm consumers, if anyone can launch a product and say it’s made by “OpenAI”.

honestly sounds like you have too many unqualified employees. best case scenario though, they all come out of this having learned a little bit more.

My simple process is:

0) agent gets its own separate git user and ssh key, separate from mine

1) branch protection rules on main, only I can approve merges into main

2) any other ssh key uses (interactive login, direct git access, etc.) are ed25519-sk keys and require a touch on yubikey.

TBH, the biggest hole is that it can be unclear exactly what process is requesting a touch on the yubikey. Apple has a head start here because they can lock down the TouchID UX relatively well, but unfortunately they don’t seem to care about building a polished developer experience for 2FA on sensitive tasks.

They are probably waiting for someone else to build the right solution and then copy/steal it.

Cobranded YubiKeys? Weird flex but ok.

Seriously though if you are letting agents do whatever they want without a PR process that requires hardware authentication or proof of presence, you are putting your code and your org at high risk.

"Right to not be locked out of performing repairs yourself" doesn't roll off the tongue quite as well.

released hatchery fish have ~10% of the survival rate of wild fish.

Is that inclusive of the entire egg->fry->fish cycle? I wouldn't be surprised if wild fish had extremely high "infant mortality" compared to hatchery fish

Sorry, I think you're reading more into this than I intended to say. My point was that the raw data itself doesn't need noise, but the published data necessarily does.

Ban it from the dataset, add it to the analysis. You can choose your own flavor of noise.

I don't know what the political undertones are here, but at some level you need to have actual ground truth, including "this person/household declined".

Publishing raw data though? That seems like shooting yourself in the foot from a national security perspective, not to mention all the other reasons not to do it.

thanks for the correction - my assumption was that VST APIs had largely the same set of functionality.

Google has been doing this for maybe a decade now with citc [0]. I don't know when Gemini is actually going to be taking advantage of this, but I do know that google has essentially a full history at "Ctrl-S" granularity, from ~every developer that works there, for at least 10 years now.

If Gemini seems stupid nowadays, it's only because they're being stingy with compute allocation.

0 - https://en.wikipedia.org/wiki/Piper_(source_control_system)

depending on your sole preferences, I bet you would like the Xero Prio Coast shoe. I just got a pair – elastic laces, slip-on ergonomics, barefoot sole, large toebox. They are fantastic.

There is zero "secret sauce" in max for live.

Ableton and Max are totally separate codebases, and "Max for Live" is just a ~VST interface between them.

I do agree that "scriptable Ableton" would be far better for production and sound design than Max, because they make all the hard parts easy: MIDI, sequencing, mixing, etc.

In Max, you have to build everything from scratch, every time.

clever girl...

The $5 trillion didn't come from nowhere. People spend money on the products because they are helpful.

However, you're right that most people at these companies are so accustomed to the "free money faucet" from ads, huge margins, etc. that it's incredibly easy to end up totally disconnected from reality. That's probably what frustrates you the most.

I will say - after having left Google just about a year ago now - that there is literally no better time to make money in tech than right now. AI is eroding the moat of all large tech companies, and skilled individuals with passion and drive can make a huge impact on the world with an incredibly small budget.

You'll make it. All of us will.

Silicon is a dog eat dog game. You release too much and you get sued for patent infringement by NPEs or competitors copy your designs and run with them. There is basically no upside unless you are running a charity like Raspberry Pi.

Margins are incredibly thin unless you're on the bleeding edge. It's not an easy business. You need to move millions and millions of chips to make a profit, and that means your FAEs are working directly with companies who are actually paying you for chips instead of trying to write perfect documentation for the open source community.

I've had the same frustration with rockchip, but if you search the lkml you'll find that they are indeed trying their best: https://lore.kernel.org/lkml/?q=rock-chips.com

the biggest issue is that actually contributing to upstream is an *incredibly* difficult and painful process.

no insider knowledge here. my assumption is that the image hash matches a training data image. "all black" is a pretty easy hash to match.

"image recitation block" means they are blocking generation of images that already exist in their database (training data).

any interest in bringing this to the arduino/maker/education community? I'd be interested in helping you put a dev board together. hit me up: jon at moeller.io

hg (fig) was definitely my favorite frontend for source control at google.

I'm not sure how to feel about this. I'm sort of half in the target audience and half not. This feels like a board for everyone, and for no one.

I thought, wow, this would be a cool way to work with rust on the RP2040/2350 but then the only books available are only for ESP devices.

A maker lab 99-projects-in-one PCB with a soldered on (or pluggable) RP2350 with companion text would scratch all the itches of my particular interest in rust and MCUs.

As someone who has a lot of C/C++ experience in the MCU world, the most mysterious part of rust on MCUs for me is the world of bit twiddling and register accesses from a safe language. I would love to have a playground to explore this kind of stuff.

And would strongly prefer open hardware like the RP2XXX family over a commercial chip like the ESP.

The meta here is to use LLMs to make things simpler and easier, not to make things harder.

Turning tokens into a well-groomed and maintainable codebase is what you want to do, not "one shot prompt every new problem I come across".

This article is a good reminder that essentially everything in your computer boils down to really precise mechanical engineering.

Any chance you'll release on macOS/Linux?

Unless it's a key that needs to be sortable (e.g. insertion order) or a metric/descriptor of some kind, I'm not sure why UUID would be overused or inappropriate for use.

i always worry about tools like this, maintained by small teams, that are so universal that even if only a small fraction of installs are somehow co-opted by malicious actors, you have a wide open attack surface on most tech companies.

e.g. iTerm, Cyberduck, editors of all shades, various VSCode extensions, etc.

The question is, are we storing the state of a chess game, or the state of a chess board?

If a game, you might also include timers or other state as well, including full position history.

This is great, I've been looking for an easy to use local chat app for me and my kids, and Adium on Bonjour has been flaky with my VLAN setup at home. Will have to give this a try...

Isn't circular funding how the entire economy works?

I can see how you could make an argument that this particular ouroboros has an insufficient loop area to sustain itself, or more significantly, lacks connection to the rest of the economy, but money has to flow in circles/cycles or it doesn't work at all.