"Handy" and "a good thing" are not the same thing.

USB and BT are security nightmares, and the browser is a fantastic sandbox. I'm pretty sure a lot of 0-days will come from there.

As always you have a choice between things existing at all on Linux or fretting about the security issues that so far have not materialized.

Definitely not for prod, but I used to have (and recommend: https://www.bitecode.dev/i/114175324/whats-a-good-name-for-a...) a giant venv just for my laptop scripts. Having one per script is too much, but none is inviting pain.

The problem with that is that eventually too many scripts means you will hit incompatibilities in Python where you can only install one version of a lib in each venv.

This trick is perfect because:

- From now on, I always install uv on all my machines anyway.

- After the first run, not only the cache make it fast, but it uses hard links so that you don't even pay the of multiple install on disk space (that's also how they are so fast in creating the envs, that and some interesting HTTP/zip tricks: https://www.bitecode.dev/p/charlie-marsh-on-astral-uv-and-th...).

- Deps are clearly defined in the script, so it's self-documenting.

For prod, shiv (https://shiv.readthedocs.io/) is probably your best bet but I'm betting uv will come up with a version of that soon.

I want to understand shiv, but I just can't grok it. I've successfully made a PyInstaller executable in the past.

Do you have any good sources for learning shiv? The docs are very sparse & lack examples and there aren't as many blogs discussing shiv as I'd hoped.

Also, do you know if shiv works on Windows?

Unfortunatly no, plus the docs are indeed not great and the UI itself is lacking.

But yes, unlike pex, shiv works on windows.

It's very different than pyinstaller in the sense that:

- it uses a standard (the zipapp format from python stdlib)

- it assumes python is already installed (it's not stand alone)

I definitely should write on article on that on Bite Code on day. Adding it to the list.

I'd read it! :) I want to understand Shiv, but I haven't even gotten it to work after a few hours tinkering, and that's usually where I give up and look to another tool.

`--offline` :)

Except you can't put that in the shebang for the first run

True, for servers you can't warm up, shiv is your best bet: https://shiv.readthedocs.io/

Or points to your own private pypi instance with --index-url.

Other neat tricks with uvx (uv equivalent of npx) to run one time commands in some contexts:

- alias download_mp3="uvx --no-cache --from yt-dlp[default] yt-dlp --extract-audio --audio-format mp3" to download sound from Youtube videos, SoundCloud pages, etc. This update yt-dlp every time, which is required given the counter measures change so often and the dl rarely affect the total processing time anyway (requires ffmpeg).

- "uvx --with <package> --with pyqt5 --from qtconsole jupyter qtconsole" starts a qtconsole (GUI version of ipython) with <package> installed so you can test it quickly. Temp venv, everything cached so next time it's instant, one single copy of pyqt5 for the current use no matter how many times you run those.

- "uvx --with virtualenv pipx run pipsi install nodejs-bin". Ok it's useless, but it's fun that it even works :)

uv's cache system and downloads optimization are quite smart, as Charlie marsh (astral CEO) explains in the interview: https://www.bitecode.dev/p/charlie-marsh-on-astral-uv-and-th...

Mozilla is getting a lot of criticism, but just for letsencrypt alone they are making the world a better place.

Before them I never used SSL for anything, because the cost/benefit ratio was just not there for my services.

Since then, I never not use it.

Two Mozilla employees were involved in starting Let's Encrypt, and the Mozilla foundation is one of the sponsors, but as far as I can tell the foundation was not directly involved in creating it.

One of the more productive uses of all those millions of dollars that Mozilla received. These days, Let's Encrypt is more important than Mozilla... and would have no difficulty receiving donations to keep the service running. It also shows what a well run technical non-profit looks like!

Spent the last 20 years hearing that.

At some point I think it's more honest to say "the python ecosystem keeps getting more awesome".

Someone, somewhere will eventually find a legitimate use case for it.

We should have a response team standing by, ready to dump thousands of tons of concrete onto that legitimate use case. A gigantic cement sarcophagus that may not solve the problem, but our descendants thousands of years from now may be better prepared to do what we can't and destroy it. The "someone" will just have to be a tragic casualty, as we won't be able to save him or her without risking the contagion spreading.

That's not tossing a coin, that's barely throwing it in the air.

To me this kills the credibility of the entire study and of the authors.

Sure, there may be something to it, but people will have a very different thing on their mind unless they check the video, which I wouldn't have done without your prompting.

It's unlikely they don't understand how misleading it is.

And somehow I have the intuition a proper coin toss will not exhibit the same properties.

Is it unlikely? If I didn't read your comment I wouldn't see any problem there. I never saw anyone flipping a coin in a different way. It's just not done much around me.

If you claim to do a research on coin tossing, the minimum is to be aware on how people toss coin.

The whole purpose of tossing a coin is randomness, so of course you want high and fast.

If the result was that no matter how high and fast you throw is you get this bias, it would have been interesting.

But now you just say "if you do things badly, things don't work".

No, the whole point of the paper (and the physics model it is verifying) is to see what happens in normal human coin tosses.

If you want to measure what happens specifically with high and fast coin tosses, then that’s an entirely different study to be done.

I don't know what a normal human coin toss is. Does the paper contain evidence/argument to justify their way of flipping a coin as "normal"?

That still sound valuable if people generally tend to do it badly? If only to provide an argument for doing it properly.

I think it's still noteworthy that what many people consider a "fair toss" is not in fact a fair toss. In other words it's interesting from an applied psychology perspective even if the physics of the phenomenon isn't particularly interesting.

a coin is likely to land on the same side. it was flipped from if it was tossed by a machine at low RPM and height consistently*

there's your paper

I'm sure you will find similar behavior with dice if you just gently let them fall from your hands instead of throwing them across the table.

This is silly.

Somebody’s grant money getting thrown down a hole…

I echo other's sentiment, ClickHouse is much more performant than TimeScale.

Interestingly, I recently interviewed Samuel Colvin, Pydantic's author, and he said when designing his observability Saas called LogFire, he tried multiple backends, including ClickHouse.

But it didn't work out.

One of the reasons is LogFire allows the users to fetch the service data with arbitrary SQL queries.

So they had to build their own backend in rust, on top of DataFusion.

I used ClickHouse myself and it's been nice, but it's easy when you get to decide what schema you need yourself. For small to medium needs, this plus Grafana works well.

But I must admit that the plug and play aspect of great services like Sentry or LogFire make it so easy to setup it's tempting to skip the whole self hosting. They are not that expensive (unlike datadog), and maintaining your observability code is not free.

What kinds of SQL queries could ClickHouse not handle? Were the limitations about expressivity of queries, performance, or something else? I'm considering using CH for storing observability (particularly tracing) data, so I'm curious about any footguns or other reasons it wouldn't be a good fit.

I'm editing the transcript right now, and he says it's more about exposing a nice API to the user.

E.G: Clickhouse interval support, which is an important type for observability, was lacking. You couldn't subtract datetimes to get an interval. If you'd compared 2 milliseconds intervals to one second ones, it wouldn't look at the unit and would say 2 ms is bigger, etc. So he had to go to the dev team, and after enough back and forth, instead of fixing it, they decided to return an error and he had to insist for a long time until they actually implemented a proper solution.

Quoting him "But like these endless issues with ClickHouse's flavor of SQL were problematic."

Another problem seemed to be that to benefit from very big scaling with things like data in Parquet at rest + local cache meant basically leaking all your money to AWS because the self-hosted version didn't expose a way to do that yourself. Click house scales fine at my size, so I can only trust him on that front since I'm nowhere that big.

Funnily after that, they moved to TimeScale, and the perfs wouldn't work for their use case.

They landed on DataFusion after a lot of trials and errors.

But really interesting perspective on the whole thing, you can see he is kinda obsessed with the user experience. The guy wrote a popular marshmallow alternative, 2 popular celery alternative and one watchdog popular alternative, all FOSS.

These kind of people are the source of all imposter syndrome in the world.

I'll publish that video next week on Bite Code if I can. If I can't, it will have to wait 3 weeks cause I'm leaving for a bit. But Charlie Marsh's one (uv's author) is up, if you are into overachievers.

One of the devs working on Logfire here. Part of it was the level of support. Like Samuel said the ClickHouse folks were not receptive to bug reports. The Timescale team is leagues ahead in that sense, they’re super responsive and helpful. Ultimately one of the reasons for choosing DataFusion was that it’s much more approachable of a project and indeed we’ve already gotten tremendous bidirectional benefit: the DataFusion team has helped us figure out some complex bits and we’ve done significant upstream contributions. By the way, DataFusion is now the fastest single node query engine on ClickBench: https://datafusion.apache.org/blog/2024/11/18/datafusion-fas...

Another reason we use DataFusion is multi-tenancy: we found it was hard to use RLS and such to implement multi-tenancy. We’ve had much better luck with the extensibility of DataFusion.