The main project ships with the multi-process qemu approach, mostly defined in their docs: https://www.qemu.org/docs/master/system/multi-process.html https://www.qemu.org/docs/master/devel/multi-process.html

But I saw some update buried in a mailing list that development of the multi-process system has been superseded by vfio-user, mostly led by nutanix: https://github.com/nutanix/libvfio-user

The nutanix repo refers to an oracle-led fork of qemu with the full vfio-user implementation built-in: https://github.com/oracle/qemu

So, they're still separate projects, right? Well, kinda. the mainline project has the vfio-user-server implementation merged in: https://github.com/qemu/qemu/blob/ac5f7bf8e208cd7893dbb1a952...

But not the client side (vfio-user-pci). So, the feature is half-baked in the mainline project.

I don't know if any of the qemu devs browse HN but it would be nice to hear more about the plans for vfio-user.

1. Dedicated operational IT admin: Dealing with repetitive tasks+requests, like managing customer’s Microsoft environment and on-site infrastructure.. Owning physical and AD infra doesn’t sound like a part-time job.

For e.g; a/v and physical IT asks; like conference room operation maintenance and support, Desktop workstation triage (have you tried turning the monitor on?). The dreaded “can you set up the printer?”…

And what if the customer sets me up as their site’s dedicated AD domain admin? Resulting in repetitive requests for user/access management CRUD operations. And/or micromanagement of tedious things like email and mailing lists…

Or

2. Dedicated software developer, website or business workflows.

Building a website and getting micromanaged or overburdened. (“can you change the logo to blue?” “Can you redesign the whole home page?”)

Or, get pulled deep into providing a business-critical software workflow or application. Fielding sales/exec requests, interpreting their business requirements, and then building AND delivering (for e.g a customer management system) is not a part time job…

How do you operate to keep the scope limited? What steps help buffer yourself from a slippery slope of full-time services?

One part I haven't quite put a handle on is where/when to use CRDs in either helm or OLM. The community still seems split on how to use CRDs.

I think the incentive of a trade/artisan economy would make more sense, and justify individualized labor (house calls for NAS reconfiguration, for instance). Like a plumbing contractor vs inspector… I like the socialized idea, but I don’t see how the implementation would work under current social service labor system and organization…

I mean, I essentially provide that to my small social community with a private media tenant.

With ZTA systems in place to accommodate remote access, maybe there is an appetite for neighbor-to-neighbor network sysadmin services? Hard to compete with the sleek silos of big box brands and their infinite marketing budget, plus 5 9s of service, though.

I’ve been running more or less the same services through hardware, hypervisor, and now kubernetes migrations and revisions. It seems to me doing things “the Linux way”, sticking to open source where possible, is resistant to the fast pace of the consumer innovation market. When anything new comes along, it’s usually relatively trivial to transfer over.

Do you have insight on what the proposal, design review, and first commits look like when architecting a brand new project? Like what do the first 30-60-90 days look like from product idea up to those o&m and sustainment activities?

[0] https://feathersjs.com/

Now if I had this kernel level network monitoring system, I probably could have had a clearer picture as to what is going on.

Really one of the hardest problems I've had with learning/deploying in k8s is trying to trace down the multiple levels of networking, from external TLS termination to LoadBalancers, through ingress controllers, all the way down to application-level networking, I've found more often than not the easiest path is to just get rid of those layers of complexity completely.

In the end I just exposed my server on NodePort, forwarded my NAT to it, and called it done. But it sounds like something like ContainIQ can really add to a k8s admin's toolset for troubleshooting these complex network issues. I also agree with other comments here that a limited, personal-use/community tier would be great for wider adoption and home-lab users like me :)

I imagine the (proprietary) stadia implementation is highly tuned to that specific implementation, with tons of control over the video source (cloud GPUs) literally all the way down to the user's browser(modern chrome implementations). Plus their scale likely isn't in the tens of thousands from a single origin. Even still, I continue to be blown away by the production latency numbers achieved by game streaming services.

And my use-case is no use-case or every use-case. I'm just a lowly engineer that has seen this gap in the industry.

>Using various content delivery networks, Mux is driving HTTP Live Streaming (HLS) latency down to the lowest levels possible levels, and partnering with the best services at every mile of delivery is crucial in supporting this continued goal.

In my experience, HLS and even LLHLS are a nightmare for latency. I jokingly call it "High Latency Streaming", since it seems very hard to (reliably) obtain glass-to-glass latency in the LL range (under 4 seconds). Usually Latency with cloud streaming gets to at least 30+s.

I've dabbled with implementing WebRTC solutions to obtain Ultra Low Latency (<1s) delivery but that is even more complicated and fragmented with all of the browsers vying for standardization. The solution I've cooked up in the lab with mediasoup requires an FFMPEG shim to convert from MPEGTS/h264 via UDP/SRT to MKV/YP9 via RTP, which of course drives up the latency. Mediasoup has a ton of opinionated quirks for RTP ingest too, of course. Still I've been able to prove out 400ms "glass-to-glass" which has been fun.

I wonder if Mux or really anyone has intentions to deliver scalable, on cloud or on prem solutions to fill the web-native LL/Ultra LL void left by the death of flash. I'm aware of some niche solutions like Softvelum's nimble streamer, but I hate their business model and I don't know anything about their scalability.

I often travel for work and was having an annoying time with Verizon’s hotspot throttling. 4G LTE should be able to run at ~5Mbps but devices connected to the hotspot get throttled down to an insufferable 400Kbps. This was super annoying and felt like an arbitrary action on Verizon’s part. I found out I could run a SOCKs proxy on my iPhone via a Pythonista script and tunnel hotspot connections through it to fool Verizon’s throttling systems. Worked great, even though the UX of launching a Pythonista script as a service and pointing clients to it was slightly clunky.

I believe urbit is the solution, just waiting for the implementation to get polished up.