kapilvt

Multiple zones impacted.

Appreciated the sans CLA contribution and GPLv3.

I’m intrigued overall by the terminal centric notion, I’ll check it out, thanks for building.

I’m curious how the remote capabilities work, I’m often / ssh/mosh into a tmux eMacs session.

The other consideration that would be useful is an explicit api for a developer to freeze the release, to prevent new file upload.

The files in a release are immutable, but a release on pypi consists of multiple files for binaries that is a cross of architecture, os, and python version. Per other comments the upload api is stateless. The consideration is an attacker adding new files to an old release

Is the name on homage to James Mickey’s classic column article in usenix ?

https://www.usenix.org/system/files/1311_05-08_mickens.pdf

Like anthropomorphism is literally in the company name… i recall reading this book as a teenager.. it does seem apt in the world to come.

https://www.amazon.com/Faces-Clouds-New-Theory-Religion/dp/0...

Assuming the Qualcomm ARM lawsuits are what’s preventing the AArch64 debut…

Sphinx does have markdown support fwiw

blood test cancer screening (free form dna), provides most of the benefits at a fraction of the costs.

Docs links lead to a 403 forbidden for me https://www.ferronweb.org/docs/

This article from isovalent introducing netkit walks through the benefits and tradeoffs

https://isovalent.com/blog/post/cilium-netkit-a-new-containe...

Sqlalchemy in general is great but the data class integration feels non pythonic to me, due perhaps to catering first to the typing crowd instead of the ergonomic one.

yeah. its not great, we had to build out a poetry plugin that worked for our cases to support a mono repo, https://github.com/cloud-custodian/poetry-plugin-freeze?tab=...

the uv support on workspaces (virtual and concrete) has me intrigued.

It was a code of conduct discussion wrt to enforcement and changes to bylaws to enable that. The actual threads

https://discuss.python.org/t/for-your-consideration-proposed...

And then a public warning

https://discuss.python.org/t/inclusive-communications-expect...

Multiarch via qemu

sort of reminds me of https://github.com/google/gvisor, re syscall interception and checking. gvisor had some significant performance impacts for io/syscall heavy workloads, but potentially seccomp/bpf could do better albeit that's mostly filtering/transform on param re more minimal touchpoint.

FAANG & Co won't touch AGPL, ditto for most enterprises. There are some exceptions in countries with weak IP enforcement on smaller players.

For large buckets key space enumeration is a significant portion of most bulk operations, especially on a potentially non optimized key space (aka hotspots), there’s a few heuristics that can be utilized, but doing an s3 inventory allows skipping that and focusing on transfer with significantly less api calls, albeit requires bucket preparation.

fwiw, we built an oss plugin for poetry on option #3 when publishing for repeatable installs to automate translation of published wheel metadata from lock file, also supports mono repos.

https://github.com/cloud-custodian/poetry-plugin-freeze

Not to be confused with Linux app armor (lsm) https://apparmor.net/

Instead this is a mobile app/ physical security thingy originating on uni campuses

Arstechnica has a solid write up. He did a lot of work making linux wifi and driver ecosystem significantly better.

https://arstechnica.com/gadgets/2024/06/larry-finger-linux-w...

I remember cursing ndis wrappers and Broadcom wifi ecosystem a long time ago, Larry helped fixed that, and mentored many others along the way.

quote from the arstechnica article "In a 2023 Quora response to someone asking if someone without "any formal training in computer science" can "contribute something substantial" to Linux, Finger writes, "I think that I have." Finger links to the stats for the 6.4 kernel, showing 172,346 lines of his code in it, roughly 0.5% of the total."

its not quite the same, roughly 60-70% of chalice code by volume is actually helping auto provision. power tools is about 70-80% code by volume is integration with other services/capabilities in aws (tracing, logging, metrics, etc). the overlap is the event routing shims/decorators.

as a previous contributor and user, I would not recommend.

as a project in the GitHub aws organization, it can not accept non amazon external maintainers.

as a project, it has a single maintainer, doing on average, an hr every few months.

as a result of both of those , its not able to keep up, or reach critical mass on community.

it has fallen fairly far behind current lambda feature set. for a simple throw away, its okay, but if you want to grow something or take advantage of new features in the underlying service capabilities or integrations, this is a dead end.

I filed this ticket a few years ago https://github.com/aws/chalice/issues/2067

There’s been a few hacker news threads on it but now we actually have a detailed post mortem from google with real details

https://cloud.google.com/blog/products/infrastructure/detail...

https://arstechnica.com/gadgets/2024/05/google-cloud-explain...

Not disagreeing but one relevant fact this article seems to leave out, that crew was not in charge of the boat at the time of the crash, which makes their situation atm a bit sad imho.

Harbor pilots were in control and navigating at the time of the crash, also don’t think they did anything wrong either. But unreliable electric systems on big ships isnt something that’s easily planned for, momentum on those things is crazy at that weight.

https://apnews.com/article/ship-pilots-baltimore-bridge-coll...

I would also note that the fix prs started landing the day after the initial commit, and other issues noted had fixes within three weeks. And of course postgresql has testing, but at universal distribution and use cases on things that will test both scheduler, network, fs, io drivers (Linux kernel, postgresql, etc, among others), some things need wider audiences or more extreme testing scenarios (SQLite for a strict subset of those considerations), and project health is measured by responding to that in a timely fashion. Afaics this is all about trunk/main, versus releases as well. So while its labeled its hard on the post (from a long time pg contributor), and yeah i might agree (cause maintainer on other software, so yeah all this resonates heavily), I’d also say its an example of things done right.

Seems like a reason to celebrate the open source model, and specifically here on how to do things better. Not to detract from universal issues for any project on maintainer availability. But, imagine a non oss database vendor with that degree of transparency or velocity, i can’t think of any that are doing anything close unless they got popped on a remote cve, aka prioritized above features or politics on a corporate dev sprint. Aka all software has bugs, it’s about how fast things are fixed, and in the context of oss imho fostering evolution among a diverse set of maintainers and use cases seems to be a better way.

As another example of that, ‘twas a PostgreSQL hacker at MS, that prevented Libxz from going wide because of caring due to perf regression and doing the analysis.

how are a single project's upstream dev and downstream distro (with tens of thousands of those) correlated?

I actually think the fork is much healthier for upstream, to get into more distros.

redhat coreos isn't really based on coreos tech at all, its ostree/rpm-tree. the kinvolk folks maintain a coreos distro based on the original tech https://kinvolk.io/coreos-eol https://www.flatcar.org

for others curious

ParadeDB - AGPL License https://github.com/paradedb/paradedb/blob/dev/LICENSE

Hydra - Apache 2.0 https://github.com/hydradatabase/hydra/blob/main/LICENSE

also hydra seems derived from citusdata's columnar implementation.

a Baltimore local harbor pilot was onboard from what I've read.