Python Bytes - #367 A New Cloud Computing Paradigm at Python Bytes

Episode Date: January 16, 2024

Topics covered in this episode: Leaving the cloud PEP 723 - Inline script metadata Flet for Android harlequin: The SQL IDE for Your Terminal. Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/367

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is Episode 367, recorded January 16, 2024. I am Brian Ocken. I'm Michael Kennedy. I guess we do have a sponsor today,

so that's awesome. But Michael, do you want to tell us why you're not? For people who are listening, maybe they hear a slightly different setup for me. For people who might watch the video, well, that right there in the background is lovely and very icy Portland, Oregon. Okay. And so I'll go ahead and put this on the screen. People can check out if they feel like they can check out the YouTube stream at like one minute, 19 seconds. This is the entrance to my house, Brian. And it looks like

an apocalypse. Just every, I would say every block or so there's like a hundred foot tree that's fallen somewhere. And it's just taken out the power in so many ways. It's like it was now it's, it was 13. Now it's 18 degrees Fahrenheit, so negative nine, something like that Celsius. No power, four or five days. Not a place for podcasting. So I'm hanging out here downtown in a hotel with the family until the power comes back on.

Hopefully today, fingers crossed. Well, hopefully, yeah, hopefully. There's actually quite a few people in Portland without power and, and yeah, it's did experience power outages and pipes bursting and things like that. And, you know, for people that are in parts of the country where they get like way colder than us, it might seem like we're just being wusses. But what we get here is often very heavy rain or heavy snow or freezing rain. And the freezing rain just weighs down trees and breaks power lines and stuff like that. Absolutely.

And this had up to 100 mile an hour winds with these really old trees. And also just the city is not really built for it. We don't get it enough that they have infrastructures for it. So it's like, oh, it snowed three inches. So just good luck with that. We're not going to do anything, right? No salt, no gravel. Just hope that works out.

So anyway, it's been all right. But yeah, different setup, Brian. So thanks everyone for the understanding indeed. And also I want to say thanks to Bright Data. We'll talk more about them for sponsoring the show. But let's talk about something contrarian, I guess you would say, Brian. Okay. You know how many people I'm sure have heard of 37 Signals, right?

David Henemeyer Hansen, he's the guy who created Ruby on Rails, most notably. But there's also Basecamp and Heymail and all that kind of stuff, right? Yeah. So needless to say, they all that kind of stuff, right? Yeah. So needless to say, they run a ton of SaaS products in the cloud. And I came across what I guess was more or less some kind of conclusion to a bunch of conversations and stuff they've been working on. And so I'll work my way backwards just a little bit, but it's pretty fascinating. And the headline on the post

is we have left the cloud. Brian, I thought we were all told to go to the cloud. I mean, we saw the picture of what happens when the clouds get angry. So I understand why you might leave the clouds, but more seriously, like clouds are supposed to save us. They save us money. They give us agility, et cetera, et cetera. Right. Yeah. So hence the contrarian aspect, right? Yeah. Look, I guess it's not like 37 signals is the same sort of places, uh, like a lot of startups, but you know, that's true. If you were in, in, um, they do make that point. Like if, if you are an early stage startup where the costs are low by all means clouded up but as i i guess one of the big lessons here is the more that you get like the cloud hooks in the sort of abstract sense into your app the the more it might set you

up for a tough time as you get bigger right so let me get through this and we can we can talk a bit more about that so uh let's so they say we stand to save over $7 million in five years from our cloud exit. And so why do they not just say, well, that's 1.2 or 1 point, whatever it is, 1.1 million per year because of our cloud exit. Because what they did is they went and they bought. So when they said they left the cloud, they didn't mean just like, we're not using Kubernetes or we're not using lambdas and serverless. Like they bought physical hardware.

Okay. So they've got these big pallets. And what they did is they bought this 20 Dell R7625 servers, which don't mean a lot to me, maybe due to some people, but it basically takes up like two server racks. And that means 4,000 CPUs, 7.7 terabytes of RAM, and almost a half a petabyte of high-speed SSD storage. And that cost them $600,000 to buy that, which is a lot of money. However, they were paying like 1.2 million a year in cloud prices and cloud to AWS basically. And so after six months, it's paid for. And the five years part is they expect this hardware to last them five years. And apparently it's super, super fast. So it's pretty interesting.

I would really recommend people go through and read this, what some of the values were. And basically what they did is they said, we're going to buy like a really big server. I know it's a bunch of kind of CPUs and stuff, but they kind of clustered into like one compute cluster. And then they came up with this thing called, it's kind of clustered into like one compute cluster. And then they came up with this thing called, it's kind of like Kubernetes called Camel, which would work for Python,

but I think originally they're deploying Rails apps on it and basically gives you zero downtime slices of this giant server. And the reason this really fascinates me is this whole philosophy here. It's also not just, hey, they're leaving the cloud because many people are running to the cloud, but it's also they're getting a really huge server, like one huge server rather than a whole bunch of small distributed servers, which also was like a little bit the way that the cloud was initially sold, right? We'll get commodity hardware. You buy a bunch of little small slices all over the place. You can buy more small slices with auto-scaling if you need. And instead they're like, no, this. And sort of along those same lines is I, a little while ago, interviewed Mark Resinovich, the CTO of Azure at Microsoft.

Super cool guy, really, really smart, but also CTO of Azure. And he talked about how they started out with a bunch of small machines as well, and they're just getting bigger and bigger ones and slicing them up for tenants to be using them. So I think this is also a really interesting trend that we're going to see more of, is like more big machines

rather than a bunch of small machines that then maybe you slice up with Docker or Kubernetes or other things. And Brian, we've hardly even talked about this yet, but that has changed the way I got to type holding, holding the mic in the wrong hand here for typing. That's changed the way that I'm running a lot of our infrastructure. So I've been thinking about this for a while, been reading this stuff. I thought I'd make it the first topic of our show, but also I had eight servers for all the TalkPython and Python Bytes infrastructure, you know, some database server stuff, one that ran Python Bytes, a bunch of services,

a bunch of small machines, right? And I'm like, you know, why am I messing with all these small machines? So I ended up consolidating like last week, all of that into one big, big server, just running a bunch of multi-tier Docker setups over there. And it's glorious, right? One machine runs great. There's a single command I typed to upgrade like 13 different web apps all at once. That means upgrade their server infrastructure, upgrade their potentially to ship their new dependencies, to rebuild them, all of that kind of stuff. One command.

Interesting. So yeah, it's really interesting. It's really different. It let me like quickly and easily throw in some more things. And also I think it's better for security, right? Like I had like little fast API apps that were just like little utility things running that I didn't pay this much attention to

as I did the other apps. And so, you know, they just didn't, they didn't get their dependencies updated as frequently and their Python versions revved as frequently. And if something happened to them, right, it's technically on the same VM, right? That's an issue.

But now they're all locked up behind like a Docker container. So it's a little more isolation as well. Anyway, I encourage people to read through. I put a bunch of different parts of this story in for the 37 signals we've left the cloud. It's worth reading. I'll just go through really quick the five values and then this is kind of a long segment.

So I'll move us on. But here are the five values guiding our cloud exit. We value independence above all else and being trapped in Amazon cloud is not great. We serve the internet. This business owes its entire existence to the societal and economic aberration that is the internet in a positive way.

And we don't want to just be locked up behind a few hyperscalers. We want to be kind of just on the internet on our own terms, spend money wisely, even if you have lots of money, you know, they're getting better value for money. Leading the way, the cloud has been sold as the answer to SaaS companies weren't so sure and they seek adventure and you bet that they do. So anyway, it's not leaving data centers. They have that in a managed data center. They just have it on hardware that they own.

So anyway, what do you think about all this? So a lot of this is, I think it's interesting that, that it affects you even like that you, that you're, you're not okay. When you said you,

you put them all on one machine're you're not okay when you said you you put them all on one machine you're not it's you don't have like a server in your basement or something no no so what i did is i instead of having a bunch of small vms at digital ocean i bought one big vm okay the one i have right now is like eight gigs four cpus but i'm pretty sure i'm going to switch to like 16 gigs and eight cpus and even that would be cheaper than what I was doing before. And it's still, and the other thing that's interesting, we're in danger of going super long in this,

but because all those different apps are sharing, let's say the final destination of eight CPUs, their spikes in performance are not at the same time. Like what makes TalkPython or Python Bytes spike in load is not the same that what makes the courses spike on load. Like a new course release or like Black Friday or something like that is very unlikely to intersect with when a podcast is released because I'm busy doing one or the other, right? And so it basically has access to all eight cores instead of that one gets two cores, that one gets one core. And even though they're sharing, like basically in aggregate, it's the same number

because the spikes don't line up, they get more capacity for whatever they're doing. It's pretty interesting. Yeah. Okay. It is interesting. Back to you. Well, let's completely go to a short topic.

And I'd like to talk about little tiny scripts or maybe big scripts, but single file applications. So single file scripts. So I wanted to talk about PEP 723, and that is inline script metadata. And one of the things that we've noticed recently, and this is authored, it's an interesting author.

So the author is Ofec Lev. I think that's how you say his name. He's the dude from Hatch. So Hatch is, I guess, in packaging. So this is around packaging. also and it also might depend on python and how we can't really tell python uh currently that a script needs uh a dependency or a particular version of python so this is an attempt to kind of fix that um and uh there's some some motivation and stuff at the top that i like you know kind of skimmed through a little bit no i read it but um the the the real uh at end, is we're going to put stuff like pyproject.toml, but you can do it in a script. And this isn't there yet, but there's an example where you just sort of do a pound sign and then a few slashes and then say script. And then after that, you can put a little bit of toml right in there as a comment. And the idea is something like uh pip right this is like the the world's uh uh craziest doc string sort of thing

right almost i don't understand so supposedly there's there's reasons behind this syntax it's the weirdest syntax i've ever seen but maybe it's just it's not quite shebang but it's kind of shebang ish yeah um but like they in their example they're saying okay well you've got a little a little script that just requires you know and this is going to be common i think actually uh requires requests and uh rich so because it's going to like grab something off the internet and it's going to print some stuff and wants to do it with color and whatever um but how do you do that without packaging it and and here's one way is to just tell python that it needs these other things um so there's a it's i don't really completely understand this like how what are the at the

back end what's going to happen what is i think the different tools will treat this different because my question is really where are these dependencies going to be installed at? Is it like, if I just say I guess it depends on the thing. So if you're going to do, if it hatch, for instance, or PIPX might handle this.

So if I say PIPX, you know, run this script and it finds this, it'll probably create a PIPX virtual environment area. And hatch will do the same thing in a different manner um but behind the scenes grab like create a little virtual environment this kind of it mostly it seems like it's hiding virtual environment and dependency installs from users but it's probably needed so anyway what do you think of this? I think it's interesting. Similar to installed, as Liz is pointing out. Sounds very similar to installed that we talked about not too long ago.

And I think it solves an interesting problem. All of these do have that little bit of a bootstrap that has to happen, right? For something, for this to work, it's not built into Python, right? And so you've got to have like one library installed that then you can use to run and kick off all the other runs. But if you somehow make that happen or get your company to agree, like we're all going to have this foundation and then it just runs, I think that's pretty excellent.

So yeah, yeah, very cool. And I think OFAC is killing it, right? He's being really creative and yeah, yeah, very cool. And I think OFAC is killing it, right? He's being really creative and working a lot of different things. And this is a PEP, right? So if this was built into Python, then all of a sudden, yeah, we can have it run. So, okay, so for some reason,

I flew right over my head that it's a PEP and not just an extension to Hatch. So yeah, this is going to be, this could be super, super important. And it was last updated in December. It's accepted now. I'm not sure how long it's been accepted, but it's around the packaging.

So PEPs with packaging are interesting because we don't really have to wait for, once they're accepted, we don't really have to wait for a release of Python because things like PIP pip and hatch and other things don't have the same release cadence as Python. So this could be, like there's a note here that says it's not going to be declared final until at least a couple of tools utilize it.

So far, there's no tools that utilize it. But their example is possibly PipRun and PipX. And probably Hatch as well, considering who wrote it. Yeah, I would imagine it might show up and might get support from Hatch as well.

Funny comments out there in the audience you guys about being Rust-inspired indeed. Brian, you want to know what else is inspiring? What? Our sponsor, Bright Data. Yeah. Indeed.

So I just want to say thank you to Bright Data for supporting the show. Check them out at pythonbytes.fm slash brightdata. And there's, go ahead, yeah. Do we want to put their stuff on there? We do, and somehow I did not quite, we didn't quite do it. There we go. Yeah. Do we want to put their stuff on there? We do. And somehow I did not quite, we did quite do it. There we go. Awesome. Yeah. So there's tons and tons of data out on the internet, unimaginable amounts of data, right? And we're lucky to live in a time where so much

of this is behind structured APIs and you can go and access it with HTTPS requests or whatever. But the truth is that most of the data is not served up over clean APIs. It's just sitting there on a web page as gnarly HTML. Maybe it's even worse than that. Maybe it's obscured behind some front-end framework like React, where when you actually look at the HTML, it just says, pull in the React app, good luck with that, and then something else happens somewhere along the way, right?

So getting access to that data can be hard. What's the answer? Well, web scraping, everyone says. Yes, true. But just like you wouldn't want to set up your production infrastructure in your home office, running web scraping jobs on a single computer, even in a data center, can lead to your program being potentially unreliable with data pinned where whatever access source source you're accessing thinks you're located right so maybe there's

different data if you're in the eu than if you're in ohio but your computer is in ohio so there you go or you know it gets blocked because of rate limiting or other types of things like that right so if you need to do professional web scraping, check out Bright Data. They have award-winning proxy network with millions of different places to access data from. And powerful web scrapers, they have even ready-to-go data sets you can download. So they've already like curated these data sets

and you can just access them and get updates from them and not even do web scraping, which is awesome. So they've got a whole marketplace for that. And everyone knows we're probably going to come back to it some more and privacy conscious stuff that I really care about. And they are both CCPA and GDPR compliant. They have low code solutions as well as Python programming models with async IO and playwright.

So if you have serious data needs and those websites that have the data don't offer an API, then you need to check out bright data. Give them a try at pythonbytes.fm slash bright data. And please use that URL. So you know that they heard from us. Thank you to bright data for supporting the show links in your podcast player show notes. So pretty awesome. All right, back to the next thing. So this is super exciting.

And it came, I believe this was sent in by Balazs. Let me check. Yeah, Balazs sent this over. Thank you, Balazs, for pointing this out. So I've had Fedor Fitzner on Python before. And we've talked about Flet. And Flet is basically Flutter, but with a Python programming API, right? Flutter is actually how we built the apps at TalkPython, right? For courses. Super cool framework,

but you're writing Dart and Dart is good, but it's not Python, right? And so it'd be great to be able to write that kind of code. Here's an example, by the way, Brian, we talked about fast UI and I said, oh, that reminds me, this sort of hierarchical code structure reminds me of Flutter. Right? And so here's the same thing,

the Flutter UI, but in Python code instead of Dart. I know the link for this code is in the show notes. You can check it out. Right. So the big news is you can now build APKs for Android. And for those of you who have not suffered the indignity of the app stores, the way you get something into the Google Play Store is you build what's called an APK, and then you send them that, they process it, and then that's what gets shipped out to run on the phones on Android.

So this means even though Flet built Flutter apps, you couldn't really deploy it. You could kind of get the Flet app and then put your Python code on there, but that's not like your app. That's like Jupyter or something like that, kind of. So this is awesome. This means that people can now build apps that go

in the App Store, at least for Android, with Flutter and Flet and Python in particular. We'll see about iOS. It's on the roadmap. So, super exciting. Yeah. I mean, I would have used Flet if I was sure I could

get it to build and ship on the different things. I'd much have rather done that than use Flutter or Dart for Flutter, but you've got to work with the building blocks you got. And this one just got better. So exciting. Yeah.

Oh, also really quick in those show notes, there's a video by this guy called Neural9. His channel is called Neural9. Walking through the steps to do that, all that built. So you want to see how it works. You can watch that eight minute video. Cool. Neat. So that's for Android apps for command line,

normal command line stuff. I was going to talk about Harlequin. So there's a lot of people that use a SQL and SQLite for, for different, different purposes, of course, for databases, but to take a look at your SQLite data,

there is a, an IDE called Harlequin. I don't think we've covered it. But it's an open source Python project that it looks like it's, it looks pretty cool. It's got like on the, we're showing on the screen, the little snippet or screenshot.

You've got kind of your tables, your data catalog on the left panel. You've got a query editor and then some query results at the bottom right. And it actually looks pretty slick for like quickly going through some data. It looks like it has hooks to go into DuckTB and SQLite. That's why I brought up SQLite.

And I'd probably use it for SQLite. I haven't used DuckDB. For people who don't know, DuckDB is also in process, very much like SQLite, but it's Columnar instead of Rowbase. So they're kind of in the same category, I guess. Yeah. Okay. Yeah, I haven't used it, but definitely SQLite.

I use that a lot. So this is kind of fun. I like command line tools. This is neat. It's kind of a short topic. Just, hey, if there's a command line interface for SQLite or DuckDB, and that's fun. It looks like it runs on Linux, Mac, and Windows, which is cool. But I was also, one of the things I've noticed is in, like, for instance, a lot of Django tutorials, Django starts with SQLite. And you, I mean, by default, it does that. And I think that you can, and then you can specify other databases. But I noticed today a discussion on Mastodon that I wanted to bring up, kind of SQLite related. Jeff Triplett posted a post by somebody else, Anze. But, okay, Jeff's comment is, this is a nice write-up about using SQLite in production with pitfalls and open questions.

I cringe whenever I see some Django Python luminary recommending people use SQLite in production. I don't care how good you are. You won't get it right, even if you think you did. Anyway, so interesting, interesting commentary there. So Anze's post was, I wrote a blog post about using SQLite in production and dealing with DB is closed errors. I'm happy to hear your thoughts. So the article is called Django SQLite and Databases Locked Error, and it walks through those.

And kind of the reality is Django doesn't, I guess, lock the database when it reads correctly. The transactions are weird. And a lot of the discussion around this really is if you're using, if you're using SQLite for a database, that's mostly read only, most people are just reading stuff. It'll probably work fine and it might work great. And it might be way less hassle than doing Postgres or something else. But if there are a lot of, a lot of transactions that are writing

to it, if you have multiple, multiple writers, then you've got issues. So just thought this was an interesting discussion. I wanted to bring it up. Yeah. That is interesting. I think it really depends on the type of app you got. Is it an analytics thing that's writing like crazy? Or is it basically like the database to your blog?

Right where it's really just you make an entry once a week if you're a good blogger you know what i mean that kind of thing and then then it's all reads i'm probably fine right so somewhere in the middle i guess like you can sort of turn that that bar or watch that gauge turn from green to red as it gets closer to like a full analytics system but yeah it's pretty interesting. Yeah, interesting discussion. Indeed. All right, what you got? Oh, we're done?

We're done. We're done, but we're not done because I have many extras. Do you have extras? I've got just a couple extras. So since I've got my screen up, I'll run through a couple extras. I started Python people podcast last summer and then kind of ran out of time trying to get the PyTest course done. And so now I'm coming back and cleaning up some things. So there's, there's a few recent episodes that finally came out. So like

I stopped in October and then picked it up in January. So we've got Will Vincent and Julian Sequeira and Pamela Fox episodes out now. So check those out. Oh, excellent. Yeah, those are all great people. And many of them have been on this show as well. So very cool. Nice to see these going there.

They provide a really interesting look, like really out of bounds looks into what people are doing. You and Paul talked a lot about um lacrosse right and empowering women and and not not the next pep and that was really interesting so yeah keep it going some of the fun bits uh are to try to try to talk to uh kind of dig deeper into stuff that like i normally don't ask about in in like for instance julian sequera um julian's a really pretty positive person so i poked at that a bit and tried to ask him like really how did you get this

mindset i mean clearly bad stuff must happen to you and we so we talk about um his his you know how does he get through it and you know keep maintaining a positive mindset so it's good anyway what are your extras for us uh let's see if I can find them here. Okay. Page find. Yes. That's the first one. Page find. So Brian, you and I, we both Hugo, right? Yeah. Hugo is awesome. Go Hugo for people who don't know. Go hugo.io. That's right. Super, super cool way to build static websites, not just blogs, but static websites that are really, really powerful. And I learned about this one from Mark Little. He also does a ton of stuff with Hugo and said, Hey, you should check out page find. So what, what is this? I have no idea.

So page find, this is not just a Hugo thing, but for all static sites. It's a fully static search library, right? So for static sites, whether this is Flask Freeze or Hugo or Pelican or whatever, this is like a post-build step thing that runs and it indexes all of your HTML or the parts that you tell it to index or tell it to, you know, you can basically say don't include this part or whatever. And it's no configuration. It has rich filtering. It has custom sorting attributes. And the way it structures, it's what it does basically is JavaScript. And it has an index that then the JavaScript reads in, but the index is broken into a bunch of pieces. So the front end stuff can like

pull just little bits of it and not pull all the results back basically right so i added this over to my website where if you're over here like brian we could see what i said about ai and check that out isn't that awesome so it it finds all the different things that we could be talking about but it also like in my document in my markdown i have like h1 h2 h3 and it will actually subdivide the results into sections, like what is in this section marked by H2 on this one page. Oh, that's pretty cool. That's really cool, right? And it also does things like, I don't know if I can see any examples here, but if you type Y-O,

it'll do you, yourself, et cetera. So it's not even just like exact word matching. It's like a really smart search engine. And all it takes is just running a script for like a couple of seconds after you build your static site and then dropping the output into a known location. Is that cool or what? That's very cool. It's one of the issues I've had when switching to a static site is not knowing how to deal

with the search part. Yeah, so I was psyched when Mark sent this over. I'm like, yes, this is going in. Yeah. The other part that I'm trying to figure out is how to get a decent contact form. So that's still to be determined. Yeah, I don't think PageFind's going to help with that. But this is cool.

This is really cool. So I recommend it. I'll add it to my stuff too. Neat. It's incredibly fast. Like search for AI and I'm on like my stuff too neat it it's it's incredibly fast like search for ai and i'm on like hotel wi-fi and it's nearly instant right so that's that is super super cool where there's a lot of sites even static sites you'll be like searching searching you'll see the little spinner you're like what is it doing like why is this search slow no it should be instant

right and that's you know very much in line with like plugging something like this into Hugo means like it's still instant. All right. I got a few more. Let's blaze them. Okay. This is not to encourage people, like more of a just interesting, hey, careful. We've got PyPI and Pip. The JavaScript world has

NPM. There's an article called When Everything Becomes Too Much, the NPMpm package chaos of 2024 an npm user named patrick js launched a troll campaign with a package called everything that depended on every npm package there so when you install it it tries to install the you know millions of npm packages and it just it destroyed it tries to install the millions of NPM packages. And it destroyed it because people were installing it. And it was just taking too much resources and so on.

So the follies of package management. How's that? Yeah, nice. All right, I'll get a little out of order here. So Matthew Fiker wanted us, and we're happy to do so, announce that the SciPy conference is coming and will be in beautiful

Tacoma, Washington this year. So if you're interested, check that out and put a link to that. And the last thing is I wrote an essay called Unsolicited Advice from Mozilla and Firefox about four things I think, three things I think they did wrong and four things I think they could do to

like absolutely both change the way that, um, the place of Firefox in the market and alleviate their, um, their insane dependency on Google. Like not anti-Google. I do stuff with Google. I love YouTube,

things like that necessarily, but I don't think they're congruent with Python, with Firefox's focus on privacy very much. And also 95% of your company's revenue from one deal with one company that's kind of at a whim could just change their mind. That's not a great place to be. I'd like to see Firefox doing well. So I thought a lot about it and wrote about it, including they should just lie about their user agent, right? Like when a website says this site runs best on Chrome and using this crappy old browser we don't know about, you know why you never see that on Vivaldi or Brave? Because their user agent is identical to Chrome. So when you get to the website, like, oh, this is my favorite one.

Perfect. We're good to go, right? How many people leave firefox because when they get to a site it says this doesn't work well you need to go get this other browser yeah it would stop saying that if firefox just said hey our work chrome you know things like that right and sure it would hurt a little it would hurt their pride but people leave firefox because the website will refuse to run right yeah and if if it it probably would work but if it's going to refuse to work then it's not gonna work right things like that so anyway this is i think it's a really fun article i had a lot of fun thinking about so people can check that out and i think um uh i don't want to dwell on this too much but the um there are like a lot of internal sites stuff so

a lot of people um do internal tools at companies and they'll do that. They'll be like, it should use Chrome. And somebody will try it with Firefox and they'll be like, oh, it doesn't work. And it probably does. It just blocks it for the heck of it. Exactly. And no one's going to update that site, right? Yeah.

It's just, yeah. Another thing that's just maybe interesting to put on people's radar is another thing a friend of mine co-founded, Wayne's, is this thing called Island, which is like a enterprise browser meant just for like giving enterprises super interesting control over things like that you're just talking about. So this is actually a super interesting one of the things I think Firebox could do, but also it's just really interesting. Island.io, people can check that out. Sounds weird. Like, why would you ever want that? And then you watch the video or listen to it and you could do, but also it's just really interesting. Island.io. People want to check that out. Sounds weird. Like, why would you ever want that? And then you watch the video or listen to it and you're like, actually, that's awesome. Okay.

Like installed. All right. Shall we joke? Yeah, let's do a joke. All right. Well, this is a Linux joke. It's more than a Python joke, honestly. So Brian, have you ever got a bike lock?

It wasn't really a combination lock for anything, but in this case it's a bike lock, right? Okay. So here's a little character says, my new bicycle lock to keep my new bicycle secure. It has three digits. Let's see. So that's a thousand combinations of what we could have. And then they start to rule out what are the ridiculous ones, right? Like one, two, three and stuff like Like, hmm, 9, 9, 8 maybe. I am not silly enough to use 6, 6, 6 or 7, 7, 7 to give full access to everyone. You know, change mod 7, 7, 7. Which gives it full access to the, rewrite access to whatever you change modded.

That is funny. Yeah, it's pretty good. I mean, obviously you wouldn't use 7, 7, 7. Maybe the wrong target market for this because it's sort of funny, but also I'm thinking, did bike locks really have three combinations, three in others or were there four? You're being way too practical. Was it like four or six or something like that? I had a smartphone smart lock once and it was awesome. You would hold your phone up to it and it would unlock.

I got it from my electric bike before my knees decided electric biking wasn't for me. And one time I was out biking with a friend and I parked it in the summer in the sun. And like the electronics bit of it got direct sunlight and it's black because it's a lock, right? Got super hot, like so hot you couldn't hardly touch it. But also so hot that like the electronics wouldn't run and I couldn't unlock it i had to like put it in the shade for an hour before i could go home i was so frustrated i like covered it with my shirt or something and just sat there till it cooled off so i could go home oh that's that's bad and then also i've seen um like the the combination really kind of doesn't matter it's how thick the rest of the lock is

because i've seen people just come up with these uh like uh battery powered just cutters and just cut the lock off um but yeah exactly it's probably not the combination but if you do have one don't use seven seven seven because clearly that's gonna i'll just say it'll just fall right off if you do that yeah just go with one two three four so yeah exactly anyway well uh thanks a lot i hope you get power back at your house soon that. Yeah. Just go with one, two, three, four. Yeah, exactly. Anyway. Well, uh,

thanks a lot. I hope you get power back at your house soon. Thanks. I hope so too. Uh, probably the, the power people said probably today, but you never know.

You never know. All right. Well, uh, good to be here with everybody later. Bye. Yeah. Bye everyone.

Bye Brian.