The Agile Manifesto says "People over process", this can be interpreted in many ways. But ideally you follow the 80/20 rule and have clear cut processes for the most frequent cases and/or liability/law/SLA stuff you can't do without. But you should have fast escape hatches as well imo where a good engineer having admin access on a platform or deploying a hot-fix is also possible.
It's an interesting article because tech articles rarely revisit the past for what kind of decisions were made and why. Thanks! Also always cool to see a Wingo article because I get exposed to a field I know very little about (how garbage collection works).
Can you explain what reproducible mean in this context? Does that mean that you can recompile everything from "scratch" or does it have a deeper meaning?
Reproducible builds ensure that you can build the same binaries with the same source code. Nothing like the current date for instance gets in the way of getting a different build.
This allows independent people to check that provided binaries don't contain malicious stuff for instance. Ultimately, it lets you download binaries instead of rebuilding everything yourself locally if the binaries have been independently reproduced.
The provided binaries may still contain malicious code but it guarantees that no malicious code has been inserted in between the build process of the published code. So if your binaries contain malicious code, you can be sure that all other users of the software version are affected, too.
does anyone practice dual build pipeline? eg: 1 by your devops team and another one by your security team and compare binaries hash later. To verify everything is reproducible.
What bothers me, for example in Python, with the function coloring is that it creeps everywhere and you need to rewrite your functions to accommodate async. I think being able to take and return futures or promises and handle them how you wish is better ergonomics.
Yeah but to be fair, that can have adverse effects if you, say, busy wait.
The sync code might be running in an async context. Your async context might only have one thread. The task you're waiting for can never start because the thread is waiting for it to finish. Boom, you're deadlocked.
Async/await runtimes will handle this because awaiting frees the thread. So, the obvious thing to do is to await but then it gets blamed for being viral.
Obviously busy waiting in a single threaded sync context will also explode tho...
As mentioned in the article, others might have different constraints that make the GIL worth it for them; since both versions of Python are available anyways, it's a win in my book.
Nice that someone takes the time to crunch the number, thanks! I know there's some community effort in how to use free-threaded Python: https://py-free-threading.github.io/
I've found debugging Python quite easy in general, I hope the experience will be great in free-threaded mode as well.
My main interaction is from the GUI where I just leave it open for days at a time. So this article stems from some of the frustrations I had using it in the terminal and not finding the same behavior I was used to.
This article is mostly about using emacs -nw which will depend on a bunch of things like how terminal input is handled! With regular Emacs, as a GUI, I typically split as well but I prefer vterm over M-x shell.
I usually use `emacsclient -nw` inside a terminal (sometimes over mosh). I've found eat[1] to be much a better than vterm at being a terminal emulator inside Emacs (inside a terminal). It flickers less, and seems to handle key forwarding a lot better. The only downside is it's slightly slower than vterm at handling a large chunk of data (e.g. cat an access log).
Sorry for the tangent: I was very eager to try vterm until I read that people have had issues with evil-mode [1]. Any idea whether eat and evil can get along?
It works somewhat more reliable (I've found vterm to break in some interesting ways depending on your cursor position even with evil-collection), but it's pretty awkward to use with evil, at least without any configuration.
For example, pressing 0 to go to beginning of line goes to before the $PS1, rather than the input beginning, going from NORMAL → INSERT inserts text at the end instead of at the cursor, Emacs motion keys doesn't work, etc. I think if I take some time to remap the key it might work, but usually I just switch to Emacs mode or just restrict myself to use only cursor key to navigate.
Glad you found it helpful! Most of it is distilled from High Performance Browser Networking (https://hpbn.co/). It’s a very well organised, easy to follow book. Highly recommended!
Unfortunately, it’s not updated to include QUIC and HTTP/3 so I had to piece together the info from various sources.
reply