igorbark

im not sure that there is a plug n play set up that will work for everyone, because as with any security boundary, each layer of hardening has a usability trade-off. i definitely feel you about the uncertainty of it all, how do you actually know everything is tight?

personally, i think either a VM or microVM is the way to go. these things are actually designed as security boundaries, as opposed to containers. and as compared to bubblewrap, you can just give the agent a whole FS to work with and run it in yolo mode, whereas with bubblewrap you have to manually bootstrap the availability of each individual dev tool and make sure its config dirs and package caches and etc are mounted in a secure way and still will probably hit perm errors all the time. and there's just way less isolation.

also, something that has limited support in harnesses but IMO would make a lot of sense is running the harness process in the host, but having all the tool calls and file system interactions delegated to the VM. that way you keep all your session data and auth keys on the main machine where it can never get into context. otoh it makes your harness part of the security boundary, so that's the trade-off.

there's also all the usability questions around how to actually get data in/out of the VM. i have a script which can push local git repos into the VM and then pull from them as a remote, so the VM can't initiate any connection with the host doesn't need to hold git credentials. but ig for someone who wants their agent to push straight to GitHub that's a waste of effort.

options i've tried or seen for the VM itself: - qemu + libvirt: takes some doing to wrangle it together, but very battle tested and configurable - crun-vm is a PoC of higher level integration layer between podman and qemu, which is a really cool way to go about it. seems maybe abandoned but i just think it's neat and very existing tools/standards oriented rather than starting a new project and brand so i mention - libkrun is a newer entrant, and several ppl have built wrappers around it: - microsandbox - smolvm (posted/discussed on here recently) - krunvm

this is all Linux oriented, it's all i know.

this logic does not hold up if the reason that labor is more expensive than parts is that the labor involved in creating those parts has been outsourced to a "shithole country"

if we're going to plug random puzzle games on this thread, IMO the most underdiscussed puzzle game of all time is Recursed, the only game i've played which properly explores recursion as a mechanic, and (MINOR SPOILER) the only game i've played which detects when you have created logical contradictions, and for each contradiction you achieve rewards you with a secret bonus level.

i definitely agree that it would've been nice to have images in the book as it was hard to get a sense of exactly how well Boquila was mimicking neighbouring plants!

but in reference to the linked article, i will say that the researchers interviewed in the book (and i got that sense for Zoe as well) were in agreement with you that the research didn't support a vision-based mechanism. but everyone agrees that the imitation is going on. the researchers in the book suggest a gene transfer-based mechanism instead! (mentioned briefly in your linked article)

not sure if you will still see this 7 days later, but the claim "we work more hours than medieval peasants did" jumped out at me so i looked into a bit and am curious if you have more thoughts on it!

i found this lively criticism of the video on reddit: https://old.reddit.com/r/badhistory/comments/16y233q/histori....

my brief takeaway was that the claim might be true if "work" means "working for an employer for wages", but not if "work" includes "necessary labor for shelter, food, clothing, survival".

but it's an interesting thought though so i'm curious if you have other related resources to dig into.

i enjoy that i cannot tell whether this is written by an AI, or by a human pretending to be an AI. my guess is human pretender!

the biggest headache i had in particular was different ways of handling environment variables, but the different adapters at OpenNext have had a rolling list of caveats/unsupported features for as long as i've been following the project so i didn't want to outright say "full". hopefully the effort on Next's side to build a standardized adapter API will help with this!

that's great to hear, thank you for the update :)

I too have had to use Next but didn't want to feel locked into Vercel.

this is the biggest effort I'm aware to run Next with a full-ish feature set outside of Vercel: https://opennext.js.org/. Supports AWS, Cloudflare, and Netlify. You can also run Next as a normal node webserver. I've only used the Cloudflare integration and it was a bit janky but worked (and seems to be entering 1.0 soon so may be less janky).

AFAIK this is completely unsupported by the Next team, but would love to be proven wrong!

you don't need to send 100kb+ of JS over the wire to build a static site in react: for example https://vike.dev supports static HTML-only output for a site built with React.

as for "why React", speaking just for myself it's really nice to just have one tool that can do everything (static HTML-only, static with JS, SPA, SSR) and not have to context switch or potentially even have to split my site into two projects just because I want to hop between one or the other approach. and React has the biggest mindshare and ecosystem.

probably adding a confirmation message the first time the alias is used for each command would be good, it would be nice to know when i'm invoking git and when i'm invoking a third party binary regardless of any exploit attempts!

culture war aside, there are many other more accurate ways to say "details omitted for brevity" than "obviously" and "it is easy to see that"

this is also something that makes me want a more interactive publishing format, though i understand the good reasons to stick to the static quo. if it's easy to see, it shouldn't be too hard to write out in a collapsible sidebar for those interested

so, yes, pythagoras did not create a dead simple mathematical model that captures the entire complexity of human musical experience several thousand years ago. BUT i think the ongoing study of consonance/dissonance is a very interesting area of the intersection of math and music

some key words/links to get you started:

- "local consonance"

- "consonance/dissonance curves"

- a seminal paper: https://sethares.engr.wisc.edu/paperspdf/consonance.pdf

- a more recent re-implementation with a cool video at the end: https://www.sebastianjiroschlecht.com/post/ondissonance/

the basic idea being, different timbres lend themselves differently to different tuning systems. so we can parameterize our models of tuning systems based on timbre

an important thing to keep in mind: consonant/dissonant doesn't mean "good/bad" or "pleasant/unpleasant". they're the output values of a mathematical model which we have a complex intuitive relationship with. other ways of thinking about it might be "simple/complex", "resolved/unresolved", "release/tension", but all are inaccurate in their own way

some areas i'd love to see progress in: - the work i've seen focuses on computational models, i.e. take a simple mathematical model of timbre, and directly compute the consonance/dissonance curve from it. but real instruments' timbre varies across many dimensions, some prominent ones being pitch, time, and dynamics. can we instead burn some CPU cycles and generate curves from a waveform? - what does this look like for triads? tetrads? ...? - put this in the browser! would make it so much easier to play with and present the ideas to less technical audiences - how can we use this to generate new instruments? can a synth automatically adjust its tuning system based on its parameters? can we start from a set of desired consonant/dissonant intervals and generate an instrument with a matching curve?

the historical expectation is that class methods will dispatch dynamically but free functions will not. so if you only have structs, functions, and UFCS you either: 1. don't dispatch on the first argument, 2. make the first argument privileged and dispatch on it, or 3. dispatch on all the arguments

the first solution is clean, but people really like dispatch.

the second makes calling functions in the function call syntax weird, because the first argument is privileged semantically but not syntactically.

the third makes calling functions in the method call syntax weird because the first argument is privileged syntactically but not semantically.

the closest things to this i can think of off the top of my head in remotely popular programming languages are: nim, lisp dialects, and julia.

nim navigates the dispatch conundrum by providing different ways to define free functions for different dispatch-ness. the tutorial gives a good overview: https://nim-lang.org/docs/tut2.html

lisps of course lack UFCS.

see here for a discussion on the lack of UFCS in julia: https://github.com/JuliaLang/julia/issues/31779

so to sum up the answer to the original question: because it's only obvious how to make it nice and tidy like you're wanting if you sacrifice function dispatch, which is ubiquitous for good reason!

this analogy breaks down on a number of levels.

1. patients invented and self-prescribed the pill originally

2. the doctor has concluded that the pills are harmful by studying what happens who do not have the illness the pills are meant to treat take the pills

3. the doctor didn't really keep track of what doses were given to different patients

i.e.

1. trigger warnings were not originally forced on people, they were created by people who found them helpful to help themselves

2. the studies in the meta analysis are all on general populations, in particular mechanical turk and college students

3. there is no discussion of the different effect different implementations of content warnings can have. for example, the only study that measured physiological responses instead of using self-reported anxiety showed the highest anxiety response. probably, because it also gave a completely general and non-specific content warning that went like this: "The next page has the link to the movie clip. Researchers have been asked to give a trigger warning for the clip". so they showed that when told some arbitrary but highly disturbing thing could happen at any point during a video, people in general will be more anxious when watching the video. and concluded that content warnings are a harmful practice.

well i'm not OP but here are some of my views:

- one important dimension of the "should" in this question is how much choice the viewer of the media has in viewing the media. this is part of why schools are such a big part of the conversation about content warnings, because the students can't just choose to opt out of readings without consequences

- another important dimension is the delivery platform and audience size. sometimes you can just ask the person who made or is showing you the thing about some very specific content you'd like to avoid or be prepared for, so specifying everything isn't as important there. otoh, if you're a giant media property with millions of viewers, maybe the cost/benefit of listing exactly when/where particular things happen looks a little better

- depending on platform, lots of detail could be more or less practical. e.g. if you're making a web page it's easy to say "content warnings: click for details > detailsdetailsdetails click for more details > detaileddetailsdetaileddetails", which easily allows the viewer to choose how much detail they want rather than picking for them, but that can be harder to pull off in other formats

- if you find this topic interesting, consider looking for literature on topics like accessibility and disability justice (not sure i could recommend a particular one since i've formed my views on this sort of thing piecemeal and through community). there is a lot of interesting moral thought on the subject of "ok so this thing is helpful to some people sometimes, sooo how much should we actually do it?"

content warnings were originally and imo ongoingly most importantly an accessibility issue. afaict, all but maybe one of the studies don't delineate between members of the population this accessibility aid is supposed to help and gen pop

language politics of whether trauma is a "disability" aside, the existence of a meta-analysis over studies which purport to study whether a disability aid works by using it with people who do not have that disability is saddening

some other limitations the i don't see the authors comment on (though i haven't read thoroughly so happy to be corrected): - the effect of different kinds of content warnings isn't discussed (some interesting dimensions are specificity and prominence) - the fact that almost all of the studies use self-reported anxiety scales, and thus it is unclear whether content warnings increase anticipatory anxiety or increase self-reported anticipatory anxiety

like with most accessibility aids the interesting questions are not "does it help". they're "who do different forms of the aid help or harm" and "morally, when should we expect or even enforce a particular level of implementation"

looking at how other accessibility aids work is helpful for answering some of these questions. to take the classic university classroom example, you could for example look at the way some departments handle students who aren't able to take lecture notes. a student can request note taking accommodation for a particular class, and then a peer volunteer (or as a fallback university employee) will take notes for that student. just like that, we don't need to have a national debate about whether it is helpful or harmful if all university professors are forced to provide note taking services for all of their students.

anyway, i guess i'm upset because i'm tired of the ongoing massive debate and apparently research industry that completely misses the point.

it basically folds (hides) the implementation code of every method in the file, giving an API-like view, but with a smooth animation shrinking the text instead of instantly disappearing it

nifty! i was thinking that new results (even if more relevant) get appended to the bottom

doesn't work for mobile unfortunately

sorry for assuming & the curt reply.

"the wife test" is a common turn of phrase relying on/reinforcing the stereotype of women as non-technical and men as technical. it's not really clear in your original post that you are literally referring to your wife's opinion of the device vs simply invoking the sexist phrase to describe the device's user friendliness for non-hackers. i hope you can see how i took it the wrong way, though i still apologize for jumping to conclusions

Haskell's type inference is optional: if you felt the above code is difficult to understand, you could manually specify the type of each statement.

In a language with a less powerful type system, you could write the same information in comments, but then the compiler wouldn't warn you if you accidentally changed the side effects of a statement.

What do you use for maps?

I only just briefly read the doc for autograd, but automatic differentiation is the strong default in TF if that's what you're asking.

This article touches on some good points. In particular, the part about trusting that the function will do the right thing is something that people who already understand recursion take for granted but is extremely crucial. However:

"Let's tweak our sum function a a bit: ... That's it."

I really dislike articles that earnestly try to convince the audience that some subject which many find extremely difficult to understand is actually very simple. My impression is that the intent is to help people who lack the confidence to engage with the topic, but in my opinion the exact opposite effect is achieved. At that point in the article, nothing about recursion had been explained and it's not reasonable to expect someone who previously did not understand recursion to read that section and come to the conclusion "that's it!" Instead they'll be sitting there, extremely confused by something which they're being reassured is actually quite simple. This is not going to help their confidence.

So while I appreciate the author's intent, I think that someone who is struggling to understand recursion might leave this article worse off than when they started. And I wish this trope would disappear from tutorials.

But for a short, isolated piece of code I assume you would be able to suggest a handful of plausible inefficiencies and explain how they could be tested for and optimized for.

A couple important benefits (there are many others, as well as drawbacks) are

1) the compiler can then warn you when you violate your own declarations before the code is ever run. e.g. it can tell you that you've mutated something you said you didn't want to, or that you've taken the sum of an int and a list.

2) the compiler can guarantee certain things at compile time and thus eliminate the overhead of checking them at runtime. since a value in Python can be anything, before performing a string operation on a string the python runtime must first check that it is a string, while the runtime of a language like rust can assume that it is because that was guaranteed at compile time.