In my reply I focused on why we need a bundled, sandboxed packaging format in the first place, since many people are sceptical just about that. So you're right in that I didn't go into any of the differences.
Snaps solve a bunch of problems that are out of scope of Flatpaks, such as CLI apps and the packaging of kernels and other hardware-level pieces. This allows for an entirely snap-based system that is immutable and atomically updated, which is essential for IoT devices to be reliable.
If you look at the history of snaps, they are an evolution of click packaging, which were created for the Ubuntu phone that is no more. But the history goes back further than that - back to Ubuntu's App Review Board and (deb based) third party app packaging system, which failed for exactly the reason that deb is an unsuitable packaging format for third party apps.
If you look at the history of Flatpaks, you'll find that their initial release was at a similar time to snaps. But given that they don't solve a bunch of problems that snaps do, what was/is Canonical supposed to do? Ditch snaps entirely and drop their IoT support? Integrate IoT support into Flatpaks? Do Flatpak upstream even want that? Look at the history of Canonical wanting to ehnance GNOME, and the history of how Unity began, to see how that doesn't seem like it would be a practical way of delivering functionality to users in a reasonable period of time.
Consider that it is Ubuntu that is at the centre of this third party app packaging problem. It's Ubuntu that everybody targets first with their third party debs. For the same underlying reason, it's Ubuntu that gets more user support requests because of bad third party debs than every other distribution. It makes sense that Ubuntu developers are best placed to understand the problem and develop a solution.
So yes, we've ended up with two parallel contenders. But I don't think it's reasonable for Canonical to have done anything differently in regard to Flatpak. It appeared at the same time while Canonical had already been working away at the problem for years, doesn't solve or even try to solve all the problems that snaps are designed to solve, and those problems appear to be out of the scope of Flatpak anyway. As much as critics frame them as like-for-like options that Canonical could just decide to switch over, they simply aren't and thus "simply switching" doesn't even make sense.
As for "another one already exists", that statement could just as well apply the other way round: look at the timelines!
Normal jeans are homotopic to a cylinder with a point removed. Leg-sewn jeans are homotopic to a torus with a point removed. Both of these can be deformation retracted to a wedge of two circles (roughly: widen the puncture as far as you can).
I know the authors---it was a pleasent surprise to see them on HN this morning! The first two in particular have been working on computer-aided investigations in pure mathematics for a few years now.
I spent a long time migrating a project to use poetry. One of the reasons I opted for poetry over others was that the lockfile retained all of the environment markers in the packaging metadata, so that the lockfile could support multiple interpreters and interpreter versions, multiple platforms, etc.
I can't speak for Poetry directly, but knowing how Python dependency resolution works: I don't think Poetry can make lockfiles not platform-specific, since package source distributions are allowed to (and regularly do) run platform-specific code for their own dependency selection logic.
For example, your package might depend on `foo`, which in turn could sniff the host OS and select the appropriate subdependency. You'd then end up pinning that subdependency, which would be incorrect on a different host OS.
(Similarly for Python versions: a subdependency might be required on < 3.7, so re-installing from a lockfile generated from an older Python could produce a spurious runtime dependency.)
I personally call ( ) "round brackets" to try and be a bit more explicit about which kind of bracket I mean, but I don't think that's a very common turn of phrase. Similarly I've picked up calling { } "brace brackets" from programming.
https://www.thinking.withportals.com/ was (is?) the big community for this. I was part of it around the time Valve released their easy map editor (the "perpetual testing initiative")---more than a decade ago now. I had the pleasure of testing the editor before its release. It was an exciting time!
Sadly that editor was geared towards single-player maps, whereas my interest was always in the coop ones. If you'll forgive the shameless plug, https://steamcommunity.com/sharedfiles/filedetails/?id=89692... was my favourite to make. I put a lot of time into that, but sadly I lost the hard drive with the map's source files some years ago. It's done quite well on the workshop---which always surprises me. I had very little idea about level design or what constitutes a fun puzzle. Beginner's luck, maybe?
It was a lot of fun/pain/curiosity to work with and fight Valve's hammer editor. I remember thinking "this feels like a tool designed to make half-life maps". I can still remember tying brushes to func_detail entities so that they wouldn't contribute visleaves. Good times!
While I'm at it: I'd recommend the "sendificator" series: https://steamcommunity.com/workshop/filedetails/?id=29165303... . These introduce a new puzzle element entirely contained within the map file. I'm guessing it must use some kind of lua script to implement it, since it's entirely contained in the map.
