breatheoften

I could imagine a wealth tax movement getting strong enough and that or the threat of it might eventually be able to change things ... :fingers crossed:

Or maybe if the trend of folks no longer working continues for long enough with enough force ...

The labor class has gotten screwed so severely for so long opting out of the labor economy is probably the most rationale option available for the majority of earth's human population ...

At first glance -- async/await mitigates a lot of my least favorite things about orm dsl's -- namely that it can be difficult to tell when the orm framework is actually going to generate a db round trip without being familiar with the implementation ... thinking back to the most recent orm i had to learn (rails) and how it was quite annoying to get started with while interacting with an existing codebase. clear suspension marking would have made the code vastly easier to follow and allow making inferences about where things were happening even as a unfamiliar with the dsl ...

I use the fish shell and have for several years now.

A few years back I did a startup with a friend -- a cross platform mobile product but with a mess of complex open-source c++ dependencies (which we forked and customized often) -- and we made the decision as we hired developers to over-specify some aspects of the machine environment to make it as easy as possible to share our development workflows. Note that "development workflow" is much more than just "i can run the app in docker" -- but rightfully includes -- I can efficiently run things in debugger, I can run the performance profiling tools in realistic ways, I can quickly execute and test a change someone else is trying to make, I can quickly share a change I'm making with someone else and be confident they can make realistic observations about it, i can setup a fast repro loop for some specific bug or feature ... etc.

We did a pretty good job of getting the know now needed for all those workflows distributed across the team reliably with low effort despite some complicated and weird build system requirements associated with our dependencies.

One of the big bang for buck tricks that helped more than I would've expected was to mandate that everyone had to use fish shell. This really reduces the number of weird effects from random things that people copy/paste into their bash initialization -- with the developer never imagining the strange knock off effects that will one day cause a tool they don't understand to behave in a flaky way for a reason they will never figure out ...

The amount of terrible things that developers randomly accumulate in their bash initialization probably can't be underestimated ... there's probably more risk of "weird problems" associated with advice on stack overflow related to bash initialization than maybe any other topic ...

So I personally think standardizing a team or startup on an alt shell can be a potentially good idea ...

As another point of evidence -- I later headed devops at another startup that took opposite perspective -- "use your own machine and your machine can be configured however you want and you just have to figure out dev workflows on your own" and it was extremely difficult to share knowledge about how to accomplish a lot of these basic workflows ... doing anything beyond the most basic ways of interacting with the codebase often involved a rather large amount of hands on dev machine troubleshooting (can you send me your .bashrc and .profile and .bash_profile? ok type these commands ... ok now you can grab my branch and try this to have a look at the thing i'm trying to change ...)

fish is reliable and stable though -- I'm not sure about using a shell that's not been around for awhile in this way ... but I'd support it I think if I already had personal experience that the shell was "reliable enough" ...

I hope they also sent the participants through new mazes after training while asking them not to echolocate -- just to help determine that they weren't getting better at sightless maze walking for some other reason (like greater sensitivity to signals from the skin and hair) ... It's kind of amazing what information our bodies perceive -- I'm thinking about the phenomenon of walking down the street talking to someone next to you while not looking ahead only to suddenly realize that you've stopped and leaned dramatically backward with your head inches from a sign you didn't see ...

I'd love to learn this echolocation skill and then volunteer to help train blind folks that haven't been taught ... I'm obsessed with echolocation.

Isn't that one of the big justifications for not bundling the standard library?

It seems to me like not shipping the std library with the runtime is potentially one of the biggest language innovations we've seen in awhile because it should allow the std library to evolve over time in a much more graceful way ... -- you'll actually be able to make breaking changes to the std library as folks who are unwilling to update their code can just use the older version (until the ossified code becomes irrelevant which eventually code that is never changed eventually will)

Who are the people behind fly? It looks to me like the first thing I've seen in awhile that actually might be "a better heroku". Anybody out there using it?

Anybody who was happy with heroku for mostly everything other than price that migrated to fly and remained happy?

Some manner of pluggable STM protocol to define a standard programming model on top of conflict detection would be pretty nice tho imo.

Features like postgres's serialized transaction isolation -- which as a non expert I think of as basically database implemented STM -- are really flexible -- but most ecosystems programming models don't really expose this capability in a full proof and natural way. You have to work to too hard to take full advantage of the capability ...

That's a very interesting and well-done experiment! I definitely learned something -- and I buy the argument that there is a way to tie a figure 8 that makes it less likely or significantly less likely to be difficult to untie ...

But I think that as rope wears and as humidity goes up -- you'll still easily find situations where the knot was correctly tied but still a lot of effort to untie after load ...

And 12-18 seconds to untie is still a lot more time required than untie'ing the double bowline ... And he's showing figure 8 on a bite so he doesn't have to take the extra seconds to undo the figure 8 after ... that's not a huge deal but the double bowline is still imo easier to tie, faster to tie, and faster/more ergonomic to untie -- and also of course, harder to verify that it was tied safely by visual inspection ...

This is a good selection of climbing knots.

I went down a rabbit hole recently surveying the "current internet wisdom" regarding the use of the double bowline with fisherman as a tie in knot for the climber ...

To recap briefly -- figure 8 follow through is the standard tie in knot that everyone is taught. It's easy to tie, easy to verify visually, and secure -- but it's hard to untie after being weighted by a fall.

That last fact matters a lot when sport climbing when taking big falls a lot is expected. Hence the several different versions of the bowline ... which is also secure if tied properly, easier to tie wrong, harder to verify visually, but extremely easy to untie after weighting ... Unfortunately there's a bit of a controversy in the climbing world regarding "what people are likely to do wrong" and whether those kinds of risks should guide people towards not using the double bowline as a tie in ... there are also multiple variations of the bowline -- some of which actually are less secure ...

Personally I've been using the double bowline with a fisherman finishing knot for years now when sport climbing -- but it's a bitch to say it ... -- but I think a worthy addition to your list (or at least a clarification that the regular bowline by itself is not really used for anything in climbing)

Bad status pages are a very bad sign in my opinion.

I had to use the IBM cloud for a project once upon a time and the status monitoring was almost always wrong ...

I really hope that as customers we can succeed in making "excellent status reporting" an absolute minimum requirement for cloud services. Observing the quality of the status page reporting history is one of the first things I do now when evaluating a new service -- and no I'm not just looking for a page that shows all greens -- I'm looking for a page that connects to some conceivably meaningful metric as well as detailed reports about major and minor outages ... something to prove that they actually even know if their service is working at a given point in time ...

The IBM cloud page was a page that tended to update in response to my own issue reports (usually if I also pointed out that nothing about the outage appeared on the status page ...). I don't think that's at all an acceptable standard ...

There are all sorts of annoyances that can manifest differently in different parts of the world when doing various forms of browser automation from different parts of the world.

Different cdn behaviors and differences in the way bot detection logic gets triggered due to geoip ip categorization lists (which definitely impact a lot of sites, often in subtle ways when - say - only a subset of the javascript assets on a page fail to load).

In my experience though, these observations are just as likely to be programmer error as they are to be legitimate claims that 'my code doesn't work because of timing issues in the puppeteer implementation.' The programming model that puppeteer exposes tends toward the rational in my opinion.

Browser automation often involves asynchronously instructing the page to simulate a click on something in order to induce some javascript in a page to run some effect, in order to repaint the dom -- and this kind of logic chain will _always_ demonstrate timing variation. But the puppeteer api's make it pretty straightforward to sequence the events that are simulated so that you can ensure you issue a click on something that exists or a waitForSomethingToExist polling based detector that will trigger reliably when a given dom node appears ... Depending on the specific page's implementation, sometimes this kind of logic can be harder to write for one page than another -- but my first guess for the reason why a given page might make this kind of logic flakey or hard to implement is more likely to be an obscure implementation detail of the page than a puppeteer bug (as a first approximation).

Surprising to me -- I used puppeteer last year for a couple of projects and found it to be extremely pleasant to use -- almost fun even! You can just pick it up and most of the api seemed relatively straightforward. I found it a little annoying to get things like reliable window placement (yes I do want the chrome incognito to be in this exact place and size everytime).

But it seemed very solid overall and especially so compared to the selenium monstrosities I remember trying to fight (and giving up) some years prior ...

why do people think function coloring is bad? In my experience it's a very good thing ...

An async function call is a massively different abstraction than a sync function call ... think about what logic is allowed to live on the other side of the async function call -- it can be literally anything without changing the caller ... sync function calls imply a very different set of expectations exist between function callers and function implementations and distinguishing between those expectations is a pure win.

If you are finding function coloring to be a big issue then the problem probably mainly lives in how you've organized your logic or codebase ... separating the colors so that things which should compose well do happens naturally in codebases which organize around data transformations (which most applications should aim toward)

I don't understand how anyone thinks Exchange can still be used ... just setting it up without obviously choosing any obviously insecure settings somewhere in the stack while also trying to support the actual needs of a diverse set of users (without even considering the presence of unpatched vulnerabilities and required patching spedds) probably exceeds the IT capabilities of 99% of corporations.

I participated in an ecological impact study off the coast of guam once upon a time and we pulled a couple of these up from the sea floor in deep sea traps ... the amount of slime covering the back deck was truly astonishing ... they also have really freaky mouths -- a circle of teeth on a squishy stalk reminiscent of the inner mouth from the movie Aliens ...

I wonder how much Chapter 11 actually makes sense as a response to something like Covid versus a swift and merciless Chapter 7 and then rebooting the business once theaters are viable again.

Assuming that a Chapter 7+then+future_reboot was possible -- who benefits the most from allowing the company to attempt to limp along until the pandemic ends intact? Are there a significant percentage of company employees who are currently getting paid with benefits during the pandemic -- or is this mainly about making it seem as likely as possible that the business will come back so that the current set of non-compensated employees will try to limp along on their own without pay in such as way that they will come back after the pandemic is over?

Wow if this actually is expected behavior then the backlash the first time this hits someone prominent in political space is definitely going to produce the regulations that you point to as currently non-existent ...

I think heterogeneous computing is actually coming this time. Increasing binary size requirements wherever portability is required will be an intended sacrifice toward that aim (but for app store based distributions - the only place required to pay the binary size tax will be in the size of the bundle provided to the app store vendor).

I think the importance of ISAs will fade away generally in favor of specifications that enable coordination of higher level memory model semantics "across" compute resources -- the cpu/compute core becomes the thing that allows you to share reads and transfer write ownership of memory as efficiently as possible between heterogeneous components that operate on the compute graph -- and many of these compute components may require various binary forms of task specific instruction encoding ...

How about a little sphere or oriented volume that magnetically levitates out of its cubby when the device is powered on -- and maybe the field could be varied to simulate different amounts of resistance ...

Another comment regarding the click and drag behavior.

One thing I would definitely expect a recent migrant to apple trackpads to experience as negative would be "force click". The apple trackpads sense force in some analogue way and if you push hard enough you can activate another action called force click. It's ridiculously easy to activate on accident when holding click while dragging -- but this "feature" can be turned off (and probably should be for most people I'd wager).

I've never tried using the middle finger for dragging -- seems awkward but i'll give it a try ... won't that activate the two finger drag operation?

Debugging code running in the production environment with access to production resources and production versions of external services is extremely useful and not always impossible to arrange -- I think it's a reasonable expectation for good development teams to have this capability in many applications ...

I was unable to run the codebase for a project I joined once and switched to using heroku one-off dynos (servers from that app's cloud provider -- these nodes are identical to production nodes excepting that they don't receive external requests and can be segregated in logs) as my development environment ... did some dumb things with ssh and tmux and was able to persuade all my tools that all the remote node's processes were accessible from localhost -- with a little finagling being able to use all the tools normally used for local development and debugging directly against production provided an extremely productive set of lenses for peering into the behavior of production resources -- especially when onboarding into the new company's codebase ...

ruby has enumerators which are quite a bit like pythons generators -- i actually think they are easier to reason about and do complicated things with -- although i learned python a long time ago and haven't tried to use generators for anything in a long time.

Seems like the way to go ... maybe even 3 layers of memory -- core local memory, memory that provides shared reader and writer consistency, and memory that provides shared reader, single writer consistency (for ownership transfers). Maybe the second form doesn't actually need to exist at all?

Minimizing ownership transfer cost across hardware elements seems like a fundamental concept to me that future architectures will need to specifically optimize in order to maximize the benefits that can be reaped from "task specific" hardware.

The more cores we add the more we have to gain by allowing them to be different from each other I think ...

rsync is hard on networks???????????

Is there any truth to this? I find it hard to believe -- most of the time rsync is tunneled over ssh which seems well enough abstracted from an optimal traffic generation mechanism that i would seriously doubt it's able to outcompete other programs for network resources in a meaningful way ... perhaps this observation evolved because there are a lot of networks that have traffic shaping rules for ssh? unfortunate effects of traffic shaping rules for ssh + low bandwidth connection + rsyncs happening over ssh + an administrator logged into an ssh port via the low bandwidth link

could maybe produce this observed (but non-sensical?) correlation?

B. I've been contemplating a mechanism based on mandatory minimum paid vacation days per year - fed provides free access to the money, corps borrow it or whatever to earn some interest -- but corps must pay employees a minimum days off per year (a large amount -- like 1-2 months per year)

The value of currency and debt has diverged too far from quality of life concerns -- days off seem a direct way to inject quality of life capital into the system and, I think, could prove an investment able to unearth very new and effective social transformation capabilities ... as well as a new shared basis from which to renegotiate and rebalance our social contracts.

Does that just mean that less capital is required to back the pool -- or is it a statement about morality?

This is a rather beautiful idea -- and sounds to be rather beautiful in implementation. Taiwan really is a special place if you've ever had the good fortune to visit.

I used to go to Kaohsiung repeatedly over the years when I did Oceanographic research -- my first visit the Love river was borderline industrial waste and it's shores kept with the theme.

From one trip to the next though it had been transformed. I don't think I've ever seen part of a city "become beautiful again" as fast as the Love river ...

There was a really interesting episode of the mindscape podcast[0] recently which discusses a system in Planaria where the expression of the way the worm grows (with one head or two) is found to be encoded in an electronic structure within the tissue of the worm -- rather than within the worm's DNA.

In a very real and observable sense, the 'blueprint' for the target worm is stored in the tissue system rather than as a 'plan' stored in the DNA itself. I think it feels surprising to see something that seems a lot like 'memory' influencing the action that results in the expression of the complete organism via the cellular level processes in this way.

I find it easy to postulate from the example of planaria that analogous 'memory encoding' systems probably exist in all sorts of cellular systems ... though I think the information theoretic reasoning referenced by the participants in that podcast for how life creates and operates these systems makes it likely that 'the existence of information storage and retrieval' in a cellular system is not at all required to imply that 'this kind of system is therefore the storage model for long term cognition'.

[0] https://www.preposterousuniverse.com/podcast/2021/02/01/132-...

Was it camera angle that made it appear to be so perfectly flat (top and bottom of rocket at same altitude) when it was in free fall or was that actually the target free fall orientation?

Interesting I suppose I didn't realize the exact definition of "naked" -- I was regarding "not naked" a bit more abstractly as "protected from inability to purchase the share when required" with "naked" implying that you did not have that protection ...

To me the deviation from the abstract definition above almost Seems like a bug in the "borrow checker" ... I'm not totally clear on why the system is designed allow the same stock to be "loaned" multiple times in this manner ...

Why is this (not particularly sound) definition of "borrow" desirable ...? I suppose this scheme has the effect of making assets appear more liquid than they might actually be -- but -- why is that good?

Doesn't it seem like there's a kind of bias introduced by this "illusion of more liquidity". Saying this mechanism "increases liquidity" feels almost like putting grease on a slope and saying "the slope is steeper" ...