zeotroph

There is third, pytype (by google), which I found pretty good but it rarely gets mentioned. However, like the others it is slow, so I hope this one is fast and supports all the pytype features (especially being able to type-check un-annotated code).

https://github.com/google/pytype?tab=readme-ov-file#pytype--...

Looking at the nice demo, I think just defaulting to asking for confirmation if there is ambiguity, instead of dazzling the user with `mergiraf solve` magic would help; there is already a `merigraf review`. Then, a confirm prompt, an option to undo the resolution completely, or just do it on a file-by-file basis (with help what command to run next).

Ah, more complex than I thought: "venvstacks allows you to package Python applications and all their dependencies into a portable, deterministic format, without needing to include copies of these large Python frameworks in every application archive.", and in "Caveats and Limitations" (please, all projects should have one): "does NOT support combining arbitrary virtual environments with each other".

Is there a helper to merge venv1 and venv2, or create venv2 which uses venv1 dependencies and on load both are merged?

And with just 3 layers: Runtime, Framework, Application. But at least you are not switching tools, and it presumably would prevent you from installing LARGE_v1.1, and then installing TINY_v2.2 in a later layer, which however upgrades LARGE to v1.2 and your docker images are now twice the size.

That's just a `git pull --rebase` away (or set pull to never merge but rebase), and all the non-merged commits are rebased onto the new upstream, and while doing the rebase the already-merged commit is dropped. The next git push origin HEAD:refs/for/main will then push the remaining commits.

> Developers just aren't very good at doing this.

GitHub provided a way to contribute, but also to avoid learning to rebase, thus making it more welcoming to devs who only know about commit and pull - that is what made it so popular. The squash then rebase or merge step is done on server side. Plus it has a very "harmless" UI, but that hides a lot of details (patchsets) and the layout wastes so much space imo.

This also means devs could avoid learning more about git, and this lowest common denominator git workflow makes it so frustrating for those of us who learned git all the way. I can't even mark a PR as "do not squash" to prevent it being merged in the default way which throws out all history.

> [GitLab] you can mark the PR to depend on another

How much user interaction does that require, and how is this visualized in the review UI? Gerrit creates this dependency with a single `git push`.

Attention Set <3 - that alone is worth another post. Gerrit really is one of the best kept dev secrets, and if you never had the luck of seeing it in person at a company where you worked at, well...

Makes me wonder what other git or dev-in-general blindspots I have.

And just visually, GitHub wastes so much vertical space, so even trying to place what belong to which patchset becomes hard.

There is one thing I miss on Gerrit when you push a stack of commits: A central place to talk about the whole of the stack, not just individual commits. This "big picture", but still technical stuff, too often happens in the issue tracker. But where to place it, I have no idea. This stack is just too ephemeral and and can be completely different on the next push.

That's exactly what Gerrit can do. When you push an x-b-c-d-e chain, these show up stacked in the UI, but you can easily cherry-pick b onto main (see that the CI passes, and the usual review), and rebase everything on top of that. If it is x, the bottom one, you can directly submit it and continue with the others.

Right, for Graphite $20/dev/month is nothing (I wonder if Enterprise is less or more more than that...), considering an ounce of review (prevention) is worth a pound of bugfixes (cure).

And when you can not get corporate to switch away from GH, then that is it. In hindsight an obvious way to (almost) print money, congratulations, but also a sad state of affairs.

But I imagine the $20k/yr is something you can easily spend on a 1/5 of a dev doing Gerrit maintenance.

From my interaction with the free part of GitHub, "diff soup" describes it very well. Does the paid version do anything better? What about GitLab, can this get near Gerrit? And then there are the external services which try to make GitHub less painful (and quite pricey, especially compared to a selfhosted Gerrit), by providing stacked diff support, did you look at these?

> if car companies where the ones liable for fixing your car

Sidenote: this one of the ideas behind Ida Aukens (controversial, and I would say misunderstood) "You will own nothing and be happy": One way to make companies liable is by making them own and maintain what they produce for the entire product cycle, and you only rent these items.

Of course this needs a very healthy and competitive market with effective regulations to prevent eternal enshittification. And maybe it doesn't work when shareholder value is everything that counts.

There is also the rarely mentioned pytype from Google, written in Python. And pyright from Microsoft is written in Typescript, pyre at Facebook in OCaml. Last time I checked, these had better type inference algorithms (Hindley-Milner?) than mypy.

https://github.com/google/pytype https://github.com/google/pytype https://github.com/microsoft/pyright

That only seems to work on btrfs, XFS, (and maybe now or very soon) ZFS and bcachefs: "[duperemove] simply finds candidates for dedupe and submits them to the Linux kernel FIDEDUPERANGE ioctl." [1] (aka BTRFS_IOC_FILE_EXTENT_SAME), and this ioctl "performs the 'compare and share if identical'" (and locking etc.) work [2]. But on those filesystems, that is a nice feature, plus it lets the tool get away with a weak hash like murmur3.

1: http://markfasheh.github.io/duperemove/duperemove.html 2: https://manpages.debian.org/bookworm/manpages-dev/ioctl_fide...

> just say `arc diff` instead of `git push`.

"just" - I bounced off Phabricator because I couldn't use native git tooling, and what mapped to where wasn't clear to me. The pure git approach of git-pr is the exact opposite of that. Sure, someone is going to write just-too-useful-to-skip-wrappers around that later, but you always know what's going on under the hood.

Good to hear, Gerrit does a lot of things right, see "stacked diffs" (or the realization that GitHub lacks these) now becoming more popular. And the patchset model is one important aspect of that, especially being able to see the difference just between patchsets - which git-pr can then do via `git range-diff` (which you already mentioned).

And even if everything git-pr does could be done by talking to the Gerrit REST-API, a simple straight forward and lightweight implementation of the "essence" of this model is very useful.

How do you envision pushing/reviewing a branch of 3 cleanly separated commits (say: write failing test, fix code, refactor) into a repo with a fast-forward/no-merge policy? The end result should of course be 3 commits, but review history should not be lost.

1) push 3 commits (author)

2) push 3 commits + 1 review commit (reviewer)

or even 2a), + 3 interleaved review commits, might be needed if the final refactor removes something.

then

3a) force-push 3 commits with the review comments applied (you mentioned --force is supported)

3b) or push 3 + 1 + (worst case 3) fixup commits, then a squash later?

If 3a), does pico have the concept of patchsets like gerrit, so the state 2) can be retrieved later?

PS: ... or even 2c, if the line I am commenting on is removed in patch 2 I would need to push a whole "review tree" (or fix conflicts in b and c):

   a -- b -- c -- review-c
    \   \
     \   `-review-b
      `- review-a

I discovered CRIU in this video below (1h) "Container Migration and CRIU Details with Adrian Reber (Red Hat)", it has a live demo and the details about how much "user space" it really is. Here with the RH podman fork of docker.

Since everyone is treating containers as cattle CRIU doesn't seem to get much attention, and might be why a video and not a blog post was my first introduction.

https://www.youtube.com/watch?v=-7DgNxyuz_o

"Numerous others" which also support MFA, have some (Web)-UI and are also open source? I only know of DefGuard[1], which aspires to do a lot more.

1: https://github.com/DefGuard/defguard discussed at https://news.ycombinator.com/item?id=36056080

Whoa, the line "Every save is uploaded, automatically [by default]" needs to qualify the non-default options. Can a company policy demand that? I hope there is a protocol-level, client-side opt-out for that, otherwise this VCS will work for the company first, and the dev is an afterthought.

"Upload every keystroke" is a huge no, and is going to be abused by companies looking for some performance metric to apply to devs (cloud IDEs are going to lead to that as well). Or things will revert to pre-git workflows where a huge number of files will remain open/changed until the final submit/push.

My workflow is to do the `grace checkpoint` equivalent and only make it public once it is presentable (and won't waste other peoples time when looking over or reviewing it). I never ever want these personal checkpoints/commits anywhere else. Mercurial/hg initially also had no easy way to have and clean up local-only commits, so for me and many others git it was.

Firefox View slowly getting more features, nice.

I hope one day it supports the very real use case of using/abusing browser tabs as bookmarks. I know I am not the only one who keeps lots of windows with currently almost 100 tabs open. Windows represent certain topics, which I finish in a day, in in months, or sometimes never - but still they re-open everytime I open Firefox. I know there are add-ons to help with "tab overflow", but native support would be better.

I was wondering why this material is so bad, it seems to be because it is mostly silica crystals. Without the resin holding it in place such a material wouldn't be possible.

90–93%: 99.9% pure silica in grits and powder form constitutes; 7–10%: Matrix of unsaturated polyester resin with catalysts to help with ambient temperature curing, according to https://en.wikipedia.org/wiki/Engineered_stone

Technically you can safely handle it, just like technically you can have lead or even asbestos in a lot of places. But some poorly paid worker ends up with ruined health in the end, so I can totally understand the ban.

If I may ask, is this mirrorfs available somewhere? The demofs from nfsserve seems to create and server a pure in-memory fs tree if I read the sources correctly.

As someone who keeps tabs open forever (as better bookmarks), resulting in tens of windows with each tens of tabs, I finally settled on Tab Session Manager [1] which allows me to "stash" these Windows and restore them later.

It seems this add-on manages and AllTabsHelper open tabs only and does not have a separate session manger (the one built into Firefox is a joke, sadly).

1: https://addons.mozilla.org/en-US/firefox/addon/tab-session-m...

And while it is there it has > 20x the impact of CO2.

Just don't dump organic waste into landfills.

Also Compressed earth blocks, which use only very little cement, should be used more.

Or Cross laminated timber, great for long-term sequestering of carbon.

https://en.wikipedia.org/wiki/Compressed_earth_block https://en.wikipedia.org/wiki/Cross-laminated_timber

...which releases methane (CH4) into the atmosphere since it is in an anaerobic atmosphere. And then the cycle is no longer the neutral CO2 -> coffee bean -> CO2 but it added CH4 to the atmosphere which heats the planet.

Ideally all bio waste is industrially composted and the generated CH4 used to generate electricity and heat, but sequestering it is also okay.

Indeed, it is less raid0 but creating a raid0 and then building a raidz on top of it.

Say you have `1, 1, 2, 2` sized devices. A raidz requires them all to be equally sized which can be done by first adding `1 + 1 = 2` and then creating a zpool with `[1+1], 2, 2`. Can this 1 + 1 step be done within zfs? Hypothetically this would be done by creating a raid0 pool and then a raidz on top via `zfs create tank raidz (raid0 a1 b1) c2 d2`, or first running `zfs create ab1 a1 ab` and use that in the next `zfs create ab1 raidz ab1 c2 d2`.