cycloptic

That's what I mean though, I see the theme, but it seems to me to be about the same as trying to fit everything into an HTTP REST API, it all falls apart when something comes along that breaks the abstraction. For example if you have something that wants to pass a structure of pointers into the kernel, you can't reasonably do that with 9p, so now you've got a special case. The debug APIs can still only return a direct memory mapped pointer to the process memory as a special case, the normal case is doing copies of memory regions over the socket, no matter how large they are. If you want to add compression to your VNC thing, or add some more complex routing to your network setup, you have to start adding special daemons and proxies and translation layers into another socket, which is not really different from what you would be doing on a more traditional Unix. Or is there another way plan9 handles these?

How is that conceptually different from IPC? The graphics system appears to somehow pass mouse and keyboard events to the client programs over a channel. At least that part seems similar to an Unix X11 setup where this would be done over a socket.

I guess I just don't see what is conceptually the difference here versus something like doing basic HTTP over a TCP socket, it seems like the same kind of multiplexing. Either way, you still have to deal with the same issues: can't pass pointers directly, need to implement byte swapping, need another serialization library if you want the format to be JSON/XML or if you want a schema, etc... So in cases where that stuff isn't important, channels would come in handy, but of course that is now getting closer to a local Unix IPC. Am I getting this right?

>No more broken than mmap of nfs.

Right, I get that's what you meant, it doesn't seem to really change much versus NFS, or DCOM, or whatever. So it's unclear what benefit is being provided by 9p here.

Also upon further research I am not sure what you mean by this is the only option, plan9 seems to suggest use of channels for other types of IPC interfaces, which seem to not be the same as 9p and are not necessarily network serializable. (Or are they?)

>there's no other option for accessing resources

That seems like it would create difficulties in porting software there. Please correct me if I'm wrong but the original plan9 appears to also have no support for shared memory or for poll/select.

>Backfilling IO on page fault is really all mmap does, conceptually.

For read-only resources yes, for handling writes to the mmapped region, that seems quite broken.

I'm guessing these applications do not have any kind of animations or smooth scrolling? That would be a simple test, make your web browser or your image viewer fullscreen in 4K and see if there is lag in the scrolling/panning/zooming.

Yes -- so if the company falls behind, maybe using some open source code could help you keep up. At least that's what I've felt looking at things on github/gitlab/etc has helped with, if done the right way :)

Then that sounds like you would want it to be an optional plugin, or a compile time flag that could be enabled for customers who want it? Why not do it, if that's what the customers asked for?

I get what you are saying and it definitely applies to the core architecture of the product, but if you have a large number of customers each with their own needs then I would be surprised if there were zero parts of the product that were modular or interchangeable.

I am not sure I see what the significant difference is, I've heard of security escapes happening in both Docker and in various hypervisors. Either way there is a risk of some privilege escalation bug that allows access to the full RAM. I think if you want isolation, both of them lose out to having a separate firewalled off machine. Also I think the companies running heavy Linux workloads on Docker are probably not interested in the ability of Qubes to run Windows or Mac, just my read on the situation from talking to some of them.

I don't know about snap but from what I have seen of flatpak, it allows for different versions of the same package to be installed, not many package managers are supporting that currently. (Nix and Guix being some notable exceptions, and those should be able to re-use some of the sandboxing bits from flatpak if they need to) Of course, that is one of the main benefits to building this on top of filesystem overlays, and why it requires a different approach from a traditional package manager, i.e. it's not just a duplication.

Edit: Live migration actually does work for containers, take a look at CRIU. (I don't know the current status of this being integrated in Docker) I never even saw this as being opposing technology anyway, for example if you need to you could migrate a container in or out of a VM.

I don't see what you mean. Qubes is great, but it is not the same thing as Docker, flatpak, or snap. Are you saying Qubes should somehow be changed so that it works similar to Docker? And if so, why wouldn't you just use Docker?

I am not saying it would be easy, it would definitely be work that someone would have to do. I'm more saying that the Godot authors would not try to threaten you or consider you a threat, it's more likely they would want to help you. Of course as a business you would not do it if your customers weren't going to pay the cost to make it worth it.

I don't know enough about the implementation of C# and Swift to say for sure, but it does seem like the open sourcing of that would making it easier to do things like port some standard library component or algorithm over from one to the other, or perhaps do something like building a Swift implementation for the CLR.

I still don't see what you mean. It sounds like you are saying the real threat would be if they had no other features that could let them stand out in the market, at which point a competitor would be able to beat them by lowering the price, possibly to zero. That can be done by any competitor and has very to do with the license -- my point is that the open source license on that "competing product" actually helps them, by allowing them to make use of the same thing without having to pay that initial investment again. And the first initial investment you made isn't lost as long as you keep a path to retaining those customers.

To put it another way, if the actual problem to the business is that they are falling behind on feature velocity and don't have the head count to keep up, re-using some features from open source code could actually help there.

I don't see how it is a threat. Assuming Godot obsoleted all their code entirely, that would still be a boon -- that's now code they don't have to spend time maintaining anymore, and they can just reuse that and focus on their core competency. (Maybe it's hosting, I don't know enough about this business)

Different languages actually isn't as bad an issue with this type of thing, as the idea with running it in the browser is that it all compiles down to Javascript or WASM.

Well, of course it would take work to compose them together, but then the pay off is that you might be able to say customers are getting the "best of both worlds."

If their customers are also asking them for hosted Godot, maybe they should also offer that as another product offering, at a competitive price, and then use that as a sales funnel into their other products? That is usually the way it goes with these open source bits.