particularly if you'd already read approximately all written material in existence about those languages. many humans are capable of learning a language from the documentation.
401k and home ownership count as "wealthy" in many circles. It's not "I can do whatever I want any time" wealth, but it does still mean "this is not an option for people who likely need it the most" which is the real issue.
How are income taxes a serious burden on “people who likely need it the most”?
Those who truly need it the most are typically well into the plus column on government transfer payments: On net, the government is paying them far more than they’re paying it.
You've got to pick some time value (if you choose this route at all), and if the goal is to prevent urgency-coercion it needs to be at least multiple hours. An extremely-common-for-humans one seems rather obvious compared to, like, 18.2 hours (65,536 seconds).
Unless you want to pick 1 week. But that's a lot more annoying.
From my read, it's explicitly a one-time thing. Presumably that means that even if you pick the "allow for 7 days" option, you can re-enable it after that without a delay (maybe with a reboot?).
>Any shell commands were executed without triggering human approval as long as:
>(1) the unsafe commands were within a process substitution <() expression
>(2) the full command started with a ‘safe’ command (details below)
if you spend any time at all thinking about how to secure shell commands, how on earth do you not take into account the various ways of creating sub-processes?
Also policing by parsing shell code seems fundamentally flawed and error prune. You want the restrictions at the OS level, that way it is completely irrelevant how you invoke the syscalls.
You can likely get away with it by being very strict and only doing it for a handful of "safe" things, e.g. `cat` has no way (that I know of) to do arbitrary code execution by feeding it a filename.
So if you allow exclusively single-quoted strings as arguments, `cat` should be fine. Double quoted ones might contain env vars or process substitution, so they would need to either be blocked or checked a heck of a lot more smartly, and extremely obviously you would have to do more to check process substitution outside strings too. But a sufficiently smart check could probably allow `cat <(cat <(echo 'asdf'))` without approval... unless there's something dubious possible with display formatting / escape codes, beyond simply hiding things from display.
I would not at all consider this to be "a sandbox" though.
And obviously that doesn't work for all, e.g. `find` can run arbitrary code via `-exec`, or `sh` for an extreme example. But you can get a lot done with the safe ones too.
"green threads" is generally how I see these systems identify as "non-colored but with async-like performance" fwiw. or "fibers". otherwise it's "async" or "coroutines".
There are different types of coroutines. The C++ type are sometimes called "stackless coroutines". With stackless coroutines you can't yield from a nested function call. Stackless coroutines are basically generators where you can pass arguments through resume, and async/await is effectively a form of stackless coroutines with yield/resume semantics that aren't fully generalized as coroutines, but oriented toward some bespoke notion of concurrency rather than as an abstract control flow operator.
"Stackful coroutines" allow yielding from any arbitrary point. They're basically fibers, except with the explicit control transfer and value passing yield and resume operators; there's no hidden or implicit control transfer like with green threads. Though, some people would argue allowing any function to yield without announcing this in their type signature is tantamount to hidden control transfer. Personally, I don't see how that's different than allowing any function to call other functions, or to loop, but in any event languages are free to layer on additional typing constraints--constraints that can be tailored to the desired typing semantics, rather than dictated by implementation details.
Stackless coroutines are typically implemented as a special kind of function whose state is allocated and instantiated by the caller. In contrast, stackful coroutines are typically implemented by reifying the stack, similar to threads. The "stack" may or not be the same as the system's ABI stack.
In stackful coroutines, unless there are additional typing constraints imposed by the language for hygiene reasons, any function can typically be called as a coroutine or use yield and resume. There's no need to compile functions into special alternative forms as call frame management works the same whether invoked from a coroutine context or not.
reply