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. And I am Brian Okken.
And I'm Michael Kennedy.
And I guess we do have a sponsor today, so that's awesome.
But Michael, do you want to tell us why you're not?
Yeah, 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.
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 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 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 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, 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, many people I'm sure have heard of 37 Signals, right?
David Hennemeyer 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 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.
Like, I guess it's not like 37 Signals is the same sort of place as like a lot of startups.
But, you know.
That's true.
If you're in, they do make that point.
Like if you are an early stage startup where the costs are low, by all means, cloud it up.
But as I guess one of the big lessons here is the more that you get like the cloud hooks in the abstract sense into your app, 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 talk a bit more about that.
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. 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 are, they bought physical hardware.
Okay.
So they've got these, these big pallets.
And what they did is they bought this Dell, 20 Dell R7 625 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, 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, 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, this whole philosophy here.
It's, it's also not just, Hey, they're leaving the cloud because, you know, 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 little while ago interviewed Mark Rusinovich, 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, 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, pulling 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 and reading this stuff.
I thought I'd make it the first topic of our show, but also I had eight servers for all the talk Python and Python bytes infrastructure, you know, some database server stuff.
One that ran Python bytes, a bunch of services and a bunch of small machines.
Right.
And I'm like, you know, why am I messing with all these small machines?
So I, 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.
And 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, FastAPI 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, frequently in their Python versions revved as frequently.
And if something happened to them, right.
It's on technically on the same VM, right?
That's an issue.
But now they're, they're all locked up behind like a Docker container.
Um, so it's a little more isolation as well.
Anyway, it's this whole, 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, 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 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.
Uh, leading the way, the cloud has been sold as the answer to SAS companies.
We're not 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?
Um, so a lot of this is, I think it's interesting that, that it affects you even like that you, but you'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, 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, it, and the other thing that's interesting or in danger of going super long in
this, but, but because all those different apps are sharing, let's say the final destination of
eight CPUs, there's spikes in performance are not at the same time.
Like what makes talk Python or Python bytes spike in, 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 they 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, 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 come recently in this, this is authored, it's 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.
And the idea is that you've got a script has depend, might have dependencies also, and it
also might depend on Python and how we can't really tell Python currently that a script needs
a dependency or a particular version of Python.
So this is an attempt to kind of fix that.
And 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 the, the, the real at the 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
like a few slashes and then say script.
And then after that, you can put a little bit of like toml right in your, as a comment.
And the idea is something like a pip.
Right.
This is like the, the world's craziest docstring 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.
But like the, 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 requires requests and rich.
So, cause 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.
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.
So there's a, it's, I don't really completely understand this.
Like how, what are the, the backend, 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 hatched 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.
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?
It gets 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, that little bit of a bootstrap that has to happen, right?
For, or something for, for this 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, if you somehow make that happen or get a, get your company to agree, like we're all going to have this foundation and then it just runs.
I think that's pretty cool.
And I think OFAC is killing it, right?
He's, 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, then all of a sudden, yeah, we can have, have it run.
So I, 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, 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 PEP and Hatch and other things don't have the same, you know, 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, so far, there's no tools that utilize it.
But their example is possibly pip run and pip X.
So, and, and probably Hatch as well.
It's considering who wrote it.
But yeah, yeah, I would imagine it might show up and might get support from Hatch as well.
Yeah.
Funny, funny comments out there in the audience.
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/bright data.
And there's, go ahead, yeah.
Do we want to put their stuff on the?
We do.
And somehow I did not quite, we didn't 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 HTTPX or 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 to whatever 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's 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 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, 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 asyncioM Playwrights.
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/brightdata.
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 Balaz.
Let me check.
Yeah, Balaz sent this over.
Thank you, Balaz, for pointing this out.
So I've had Fyodor 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 Talk Python, 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.
And 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 Flutter built Flutter apps, you couldn't really deploy it.
You could kind of get the Flutter 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 Flutter and Python in particular.
We'll see about iOS.
It's on the roadmap.
So super exciting.
Yeah.
I mean, I would have used Flutter if I was sure I could get it to build and ship and on the different things.
I'd much rather have done that than use Flutter or a Dart, you know, for Flutter.
But, you know, you 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 build.
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 SQL and SQLite for different purposes, of course, for databases.
But to take a look at your SQLite data, there is 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 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.
They'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 DuckDB and SQLite.
That's why I brought up SQLite.
And I'd probably use it for SQLite.
I haven't used DuckDB.
Yeah, for people who don't know, DuckDB is also in process, very much like SQLite,
but it's columnar instead of row-based.
So they're kind of in the same way.
Oh, okay.
I guess.
Yeah.
Okay.
Yeah, I haven't used it, but definitely SQLite use that a lot.
So this is kind of fun.
I like command line tools.
This looks neat.
It's kind of a short topic.
Just, hey, this is 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 commentary there.
So Anze's post was, I wrote a blog post about using SQLite in production and dealing with DB.
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 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 transactions that are writing to it, if you have multiple writers, then you've got issues.
So just thought this was an interesting discussion.
I wanted to bring it up.
Yeah.
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 here 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 it's all reads.
Probably fine.
Right.
So somewhere in the middle, I guess, like you can sort of turn 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.
Hey, interesting discussion.
Indeed.
All right.
What you got?
Oh, 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've been I've kind of start.
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 Seguera 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 know, like you and Paul talked a lot about lacrosse.
Right.
And empowering women and and not not the next pep.
And that was really interesting.
So keep it going.
Some of the fun bits are to try to try to talk to kind of dig deeper into stuff that like I normally don't ask about in.
Yeah.
Like, for instance, Julian Seguera.
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 so we talk about 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?
Let's see if I can find him 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 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, 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 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 like 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 like 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 page find is 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 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, let's blaze them.
Okay.
This is not to encourage people like more of a, just an 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 NPM 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.
Like, cause 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 Feikert 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, you know, three things I think they did wrong and four things I think they could do to like absolutely both change the way that, the place of Firefox in the market and alleviate their, their insane dependency on Google.
Like I'm not anti-Google.
I, 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?
Cause 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, we're 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 going to 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 it.
So people can check that out.
And I think, I don't want to dwell on this too much, but the, there are like a lot of internal sites stuff.
So a lot of people, do internal tools at companies and the, 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, it just blocks it for the heck of it.
So.
Exactly.
And no one's going to update that site.
Right.
It's just, yeah.
Another thing that's just maybe interesting to put on people's radar is another thing.
Um, a friend of mine co-founded 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 Firefox could do, but also it was 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're like, actually, that's awesome.
So.
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?
One of those, 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, hmm, nine, nine, eight, maybe.
I am not silly enough to use 666 or 777 to give full access to everyone.
You know, change mod 777, 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 777.
I may be 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 of those, or were there four?
You're being way too practical.
You're 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 went lock.
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 bad.
And then also I've seen like 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 like
battery powered just cutters and just cut the lock off.
Yeah, exactly.
It's probably not the combination, but if you do have one, don't use 777 because clearly that's
going to, it'll just fall right off if you do that.
Yeah, just go with one, two, three, four.
Yeah, exactly.
It's fine.
Anyway.
Well, thanks a lot.
I hope you get power back at your house soon.
Thanks.
I hope so too.
Probably the power people said probably today, but you never know.
You never know.
All right.
Well, good to be here with you.
Talk to everybody later.
Bye.
Yeah.
Bye everyone.