rlyshw

This is kinda getting at a core question of epistemology. I’ve been working on an epistemological engine by which LLMs would interact with a large knowledge graph and be able to identify “gaps” or infer new discoveries. Crucial to this workflow is a method for feedback of real world data. The engine could produce endless hypotheses but they’re just noise without some real world validation metric.

I’ve thought about doing this, but a few reservations came up when I considered getting started with a family friend. I just pictured a contracted ”IT MANAGER” getting rabbit holed into some time-sink extreme;

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?

Helm charts are pretty standard, git/kube-native, and lead much more nicely into the more sophisticated operator/controller model.

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.

USPS might be mired in fed scale problems. Maybe a Library is more appropriate? At least, more directly accessible at the local level. I’m just not sure how exactly that would work, or operate thru existing library organization…

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 know that this is a typical HN post, assuming everyone should become a Linux sysadmin. But related to the parent, and recent developments in Zero Trust Access products, I wonder if there is a pathway towards neighborhood-scale sysadmin services.

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.

Linux has been pretty stable for decades now. I’ve been using the same core configs and bulk data in my home compute environment basically since I started using Linux. Remote repos for any syncing needs, then just tar/rsync bulk archive data over. Store longer term or stale data on older decommissioned HDDs.

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.

Seems like a lot of ongoing o&m and sustainment of an existing product, similar to any other day-to-day.

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?

Except the Spotify model is also rife with issues. Artists generally hate Spotify and hardly make a living off of “pay per stream”. Most of them still very much depend on tours, merch, and, at the higher level, brand deals to make any money off of their craft.

I recently had an issue where my UDP service worked fine exposed directly as a NodePort type, but not through an nginx UDP ingress. I _think_ the issue was that the ingress controller forwarding operation was just too slow for the service's needs, but I had no way of really knowing.

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 :)

Ha, this is great. I just spent the holiday break launching a kubernetes cluster in my home lab, on which I’ve deployed a Minecraft server to play with my friends. I guess with this I could manage my Minecraft kubernetes deployment WITHIN the world itself. One creeper and the whole server comes crumbling down. It would be a very risky game.

Love this. A great point. HLS via CDN is really just "downloading files but the source is provided kinda fast"

Yeah as the sibling comment mentions these WebRTC implementations do not scale. While you "can hook it up" for hyper-specific applications and use cases, it does not scale to say an enterprise, where a single SA needs to support LL streaming out to tens of thousands of users.

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.

A quick search for "latency" in here has one little hand-wavey blurb about Mux working to optimize HLS.

>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.