catern

>What would be the syntax for promise pipelining, if you aren't using promises to start with?

Oh, great point! That does seem really hard, maybe even intractable. That's definitely a reason to like cooperative concurrency, huh...

Just to tangent even further, but some ideas:

- Do it the ugly way: add an artificial layer of promises in an otherwise pre-emptive, direct-style language. That's just, unfortunately, quite ugly...

- Use a lazy language. Then everything's a promise! Some Haskell optimizations feel kind of like promise pipelining. But I don't really like laziness...

- Use iterator APIs; that's a slightly less artificial way to add layers of promises on top of things, but still weird...

- Punt to the language: build an RPC protocol into the language, and promise pipelining as a guaranteed optimization. Pretty inflexible, and E already tried this...

- Something with choreographic programming and modal-types-for-mobile-code? Such languages explicitly track the "location" of values, and that might be the most natural way to represent ocap promises: a promise is a remote value at some specific location. Unfortunately these languages are all still research projects...

I totally agree with your framing of the value of async/await, but could you elaborate more on why you think that this behavior (which I would call "cooperative concurrency") is important for (ocap?) RPC systems? It seems to me that preemptive concurrency also suffices to make RPC viable. Unless you just feel that preemptive concurrency is too hard, and therefore not workable for RPC systems?

Rationalists and EAs spend far more time praising the Catholic Church and other religious groups than criticizing them - since they spend essentially no time criticizing them, and do occasionally praise them.

>If you take enough steps back and really think about it, the only synchronization primitive that exists is a futex (and maybe atomics). Everything else is an abstraction of some kind.

You're going to be surprised when you learn that futexes are an abstraction too, ultimately relying on this thing called "cache coherence".

And you'll be really surprised when you learn how cache coherence is implemented.

Emacs 30 has a native graphical port to Android, maybe you can just use that on any Android device.

Well, that's not fundamental. There are plenty of projects that support generating typed bindings for libraries in one language for use by programs in another language. You could do the same thing here.

Is stackfulness required for what the grandparent describes? It seems possible to do this stacklessly: all functions implicitly compile down to a state machine, but futures are never visible.

What do you suggest as an alternative way to express these concepts?

Colloquially, "library" and "service" have 95% of the correct connotations.

Ultimately, it can't. Proprietary software has fundamental limitations that force proprietary software developers to choose technically inferior designs. It's why in the long run proprietary software is doomed.

Do you have better suggestions for what words/phrases to use to refer to these two categories?

If you predictably do that then the pilots won't speak truthfully in therapy in the first place.

The only way to get the lesser benefit of therapy is to precommit to not report suicidal thoughts.

The greater benefit of "pilots honestly report their suicidal thoughts and then they are stopped from flying" is simply impossible to achieve, and if you foolishly try to get it anyway then you won't even get the lesser benefit.

I think you may have misunderstood the problem that this article is solving.

You've implemented something which kills all your child processes when you exit cleanly, but which leaks child processes if you exit uncleanly. This is, frankly, easy to do, and not interesting. It's not a "problem".

The article is solving the problem of: how do I make sure my child processes die even if I exit uncleanly? That's an actual hard problem to solve.

It is unfortunate that there are poorly-managed projects with poorly-managed mailing lists (just like there are poorly-managed projects on Github), but sourcehut at least requires a properly-managed mailing list, and I think you should evaluate this workflow on that standard. Tell poorly-managed projects to move to sourcehut, if you want to fix this issue.

You don't have to subscribe to send a patch to a mailing list.

That specific workflow precludes reviewing the patch via quoting and making inline comments, which is the normal way to review patches when sending them via email.

When a process does, its children are reparented to init, not to its parent. So the grandparent can do nothing.

It requires a bit of annoying machinery since you have to dedicate a process to being a subreaper. Still it's probably the best option, I made https://github.com/catern/supervise with it, see also https://catern.com/process.html

An important thing omitted in this post, which makes work-stealing less attractive, is that one core being idle can actually improve performance of other cores. Today's CPUs basically have a fixed energy budget, and if one core is idle that means more of that budget can go to other cores.

In other words, core utilization is less relevant today - what you care about is energy utilization (which is shared across cores).

Of course, there's a point at which this stops being relevant - if you have multiple sockets for example, this won't apply. But work stealing across multiple sockets is so expensive anyway that you would never want to do it. You might as well work-steal across machines at that point - something which is indeed useful sometimes, but usually niche.

The problem is setuid. Just get rid of that and this becomes irrelevant.

That's actually a git issue - git is notoriously slow on OS X, and magit uses git heavily in a way that is correspondingly slow.

I didn't know 9p had promise pipelining!

Or more specifically, it seems to have client-chosen file descriptors, so the client can open a file, then immediately send a read on that file, and if the open fails, the read will also fail (with EBADF). Awesome!

This is great, but "promise pipelining" also needs support in the client. Are there 9p clients which support promise pipelining? For example, if the user issues several walks, they're all sent before waiting for the reply to the first walk?

Also, it only has promise pipelining for file descriptors. That gives you a lot, definitely, but if for example you wanted to read every file in a directory, you'd want to be able to issue a read and then walk to the result of that read. Which 9p doesn't seem to support. (I actually support this in my own remote syscall protocol library thing, rsyscall :) )

I respect the attempt to shift perspective very much, but you only engaged at a surface level with the reasons I listed.

>The first is that it's not easy; but `docker run` or `podman run` is easy.

I was referring to easy use from a full fledged programming language. When you start a subprocess in your programming language of choice, do you always run it in a container? I seriously doubt it, and the reason for that is because it's hard.

>The second reason was about gdb

No, the second reason was about user namespaces, which break many things including ptrace, which in turn breaks gdb, as just one example. There's lots of useful tracing and monitoring software which makes occasional use of ptrace.

>if multiple processes should be managed as a single unit (including the case when we'd want to terminate a whole group of processes) they should run in the same container

Yes, that's true. And indeed, scripting use cases often have that characteristic, where everything can be terminated at once at the end. You can compare this to missile-style garbage collection: Just never free your memory/processes. Unfortunately, long-lived applications both need to free their memory over time and need to clean up their processes over time.

People worry about Net Neutrality because it was a fantastically successful astroturfing campaign by internet media companies. No similar campaign against FOSTA-SESTA succeeded.

Just as one data point, I have never used straight.el, package.el as it exists in even Emacs 26 is sufficient for me for all my packages. I think this is true for the majority of Emacs users that use packages.

I do this, I host my website on my desktop. It's nice to have just a single computer instead of many. http://catern.com/computers.html

Confounded by health.

No mention of this or any confounds in the paper. Which leads me to believe this paper is clickbait "science".

Yes, I came here to say this, these are not command line games.

I'm tempted to make some kind of gimmick website or Twitter account, "Not Command Line", which posts examples of this confusion...

Fascinating take! I've never heard this view before, thank you for sharing it!

One can embrace this philosophy for one's personal computing too http://catern.com/computers.html although it's not for everyone

>Bell Lab's Plan 9, for example, did so in part in the late 1980s.

Plan 9 did not support forking to remote machines and was not a single system image system. Its support for running a program on a remote machine was a completely userspace program.

If you say Plan 9 was an example of teleforking, then so is ssh. That might be a reasonable categorization, but both Plan 9 and ssh are very different from LOCUS and other SSI systems.