Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We hacked Gemini's Python sandbox and leaked its source code (at least some)

landh.tech

Post reply on HN
Print view View original

141–150 of 151 posts

Re: We hacked Gemini's Python sandbox and leaked its source code (at least some)

#141

Post by waych »

saagarjha wrote: post #107
waych wrote: post #87

Earlier quoted context omitted.

The "runtime" is a google internal distribution of libc + binutils that is used for linking binaries within the monolithic repo, "google3". This decoupling of system libraries from the OS itself is necessary because it otherwise becomes unmanageable to ensure "google3 binaries" remain runnable on both workstations and production servers. Workstations and servers each have their own Linux distributions, and each also…

Of course, this meant that some tools got stuck on some old glibc from like 2007.

IIRC Google has a policy whereby all google3 binaries must be rebuilt within a 6-month window. This allows teams to age-out support for old versions of things, including glibc. grte supports having multiple multiple versions of itself installed side-by-side to allow for transition periods ("v5" in the article).

Re: We hacked Gemini's Python sandbox and leaked its source code (at least some)

#142

Post by saagarjha »

waych wrote: post #141
saagarjha wrote: post #107

Earlier quoted context omitted.

Of course, this meant that some tools got stuck on some old glibc from like 2007.

IIRC Google has a policy whereby all google3 binaries must be rebuilt within a 6-month window. This allows teams to age-out support for old versions of things, including glibc. grte supports having multiple multiple versions of itself installed side-by-side to allow for transition periods ("v5" in the article).

Sure, I'm talking about things linked against grtev4

Re: We hacked Gemini's Python sandbox and leaked its source code (at least some)

#143

Post by topsycatt »

ryao wrote: post #73
topsycatt wrote: post #5

That's the system I work on! Please feel free to ask any questions. All opinions are my own and do not represent those of my employer.

I imagine you need to make and destroy sandboxed environments quite often. How fast does your code create a sandboxed environment? Do you make the environments on demand or do you make them preemptively so that one is ready to go the moment that it is needed? If you make them on demand, have you tested ZFS snapshots to see if it can be done even faster using zfs clone?

Sorry for the delay in replying!

We actually use gVisor (as stated in the article) and it has a very nifty feature called checkpoint_restore (https://gvisor.dev/docs/user_guide/checkpoint_restore/) which lets us start up sandboxes extremely efficiently. Then the filesystem is just a CoW overlay.

Re: We hacked Gemini's Python sandbox and leaked its source code (at least some)

#144

Post by topsycatt »

TechDebtDevin wrote: post #102
topsycatt wrote: post #15

Earlier quoted context omitted.

That's a good question! It's not incompatible, it's just a matter of getting the flow right. I can't comment too much on that process but I'm excited for the possibilities there.

Have you by chance read this paper: https://agent-gen.github.io/

I have not. I'll take a look, thanks!

Re: We hacked Gemini's Python sandbox and leaked its source code (at least some)

#145

Post by topsycatt »

simonw wrote: post #134
12345hn6789 wrote: post #119

Earlier quoted context omitted.

What would the benefit of doing this be?

It's documentation. Makes it much easier for people to know what kind of problems they can solve using Code Interpreter. It's a bit absurd that the best available documentation for that feature exists in my hacky scraped GitHub repository.

That's a very good point. Let me speak with some folks and see what I can do.

Re: We hacked Gemini's Python sandbox and leaked its source code (at least some)

#146

Post by fennecbutt »

MoonGhost wrote: post #106
fennecbutt wrote: post #96

Earlier quoted context omitted.

Idk, I used to want to work for Google but I'm not so sure anymore. They built an awesome landscaper next to my office in London. But the UX and general functionality of their apps and services has been in steep decline for a long time now, imo. There are thousands of examples of the most basic and obvious mistakes and completely uninspired, sloppy software and service design.

> obvious mistakes and completely uninspired, sloppy software and service design. That's something you can work on to improve. A few years back I wanted to work for FAANG big company. Now I don't after working for smaller but with 'big' management. There are rats races, dirty tricks. And engineers don't have much control on what and how they are doing. Many things decided by incompetent managers. Architect position i…

Well exactly. Sure I could try hard to pass some Google interview with silly exercises and be lucky and get selected most likely by some interviewer who isn't one of the devs but works in HR.

But why? When they have so much management now and have just gotten so big that it'd probably be impossible to get anything done.

Re: We hacked Gemini's Python sandbox and leaked its source code (at least some)

#147

Post by ryao »

topsycatt wrote: post #143
ryao wrote: post #73

Earlier quoted context omitted.

I imagine you need to make and destroy sandboxed environments quite often. How fast does your code create a sandboxed environment? Do you make the environments on demand or do you make them preemptively so that one is ready to go the moment that it is needed? If you make them on demand, have you tested ZFS snapshots to see if it can be done even faster using zfs clone?

Sorry for the delay in replying! We actually use gVisor (as stated in the article) and it has a very nifty feature called checkpoint_restore ( https://gvisor.dev/docs/user_guide/checkpoint_restore/ ) which lets us start up sandboxes extremely efficiently. Then the filesystem is just a CoW overlay.

Thanks for the response. I had misread the article’s description of gVisor and mistook it as something meant to protect the rest of the system rather than something that handled the filesystem part of the sandbox. It is an interesting tool.

Re: We hacked Gemini's Python sandbox and leaked its source code (at least some)

#148

Post by Mindwipe »

GrayShade wrote: post #139
7bit wrote: post #28

Earlier quoted context omitted.

It can't do shit, especially in some EU countries, where it can do even less shit. Setting timers reminders, calendar events. Nothing. If they kill the assistant, I'll go Apple, no matter how much I hate it.

Just tested, you need to enable "Gemini Apps", but they remember your interactions for 3, 18 or 36 months instead of 3 days.

Gemini Apps doesn't offer the ability to talk to the clock app on Samsung devices.

Re: We hacked Gemini's Python sandbox and leaked its source code (at least some)

#149

Post by worldsavior »

lqstuart wrote: post #101

So by “we hacked Gemini and leaked its source code” you really mean “we played with Gemini with the help of Google’s security team and didn’t leak anything”

Sad that I didn't read this comment before reading this article.

Re: We hacked Gemini's Python sandbox and leaked its source code (at least some)

#150

Post by dieortin »

fennecbutt wrote: post #146
MoonGhost wrote: post #106

Earlier quoted context omitted.

> obvious mistakes and completely uninspired, sloppy software and service design. That's something you can work on to improve. A few years back I wanted to work for FAANG big company. Now I don't after working for smaller but with 'big' management. There are rats races, dirty tricks. And engineers don't have much control on what and how they are doing. Many things decided by incompetent managers. Architect position i…

Well exactly. Sure I could try hard to pass some Google interview with silly exercises and be lucky and get selected most likely by some interviewer who isn't one of the devs but works in HR. But why? When they have so much management now and have just gotten so big that it'd probably be impossible to get anything done.

That’s now how the hiring process works at Google. You seem to be making decisions based off assumptions
Post reply on HN