80fj0348i
80fj0348i on Hacker News
Most of the other container runtimes don't require root for many of the use cases in which Docker does.
> Wasn't it basically a competitive FPS? I don't want a competitive FPS in my single player RPG.
No, it was a co-op third person shooter, and one of my favorites I've ever played. It was arguably better gameplay than the main game. It even still has an active playerbase.
The launch version required a small amount of MP for the best ending, but it was pretty quickly patched.
Browsers also maintain their own CRLs separate from the OS.
For desktop/most server software, they usually defer what to trust to the operating system, so if you've updated your OS' cacerts package they would likely have been revoked.
The really fun stuff are stuff like:
1. embedded and IOT stuff that doesn't ever get OS updates or even have an OS. People are using this to MITM stuff like smart TVs and household appliances and then pwn them.
2. In some cases a Linux container is run in a context where the OS is hidden from it (think serverless/container as a service type platforms). It might not have access to the OS trust store and have to fall back on the one built into the stdlib.
You put the SaaS into a Box your customers can install into their datacenter!
I have my friends and family using tailscale + jellyfin. Their only complaint is not having an easy way to watch on Xboxes. I convinced a few of them to plug old laptops into their TVs which is working fine.
A media streaming system is a lot cheaper than the media. A lot of people bought Plex when it was a "buy once keep forever" payment model.
Honest question: Does anyone actually use Amazon Linux in production? Everywhere I've every worked used a mainstream distro for cloud servers, like Debian, Ubuntu, Red Hat or SUSE.
> Just a couple days ago I had one trying to explain to me that all other languages are worse because you don't understand what the machine is doing under the hood.
Point out to these people that compilers rewrite your code quite significantly so the choice of language matters a lot less than the choice of debugger, profiler, etc.
1. The tools available in vanilla have improved a lot recently and 2. LLMs have made niche skills/knowledge more accessible. SPAs still have their place but the average CRUD app is now really well served by vanilla or lightweight libraries like HTMX.
I think this is going to kill fast-paced competitive gaming. The cheat scene is going to go bonkers, to the point where competitive games will require the server to become fully authoritative (i.e. tick-based server-heavy games like MMOs, or full on cloud streaming gaming). Neither are compatible with very fast paced games.
My guy, SWE ICs are making high six to low seven figure annual TCs nowadays in SF. Not exaggerating. RSUs and ESPPs be crazy these last couple of years.
...$530K cost to employ is actually not unheard of for a US based software company, actually. (i.e. including office space, equipment, healthcare, benfits and corporate taxes). Maybe slightly on the high side though.
Most of the costs to provide digital services are salaries for the employees. You need engineers, support staff, lawyers, and some supporting roles like finance and security/compliance to meet the legal and contractual obligations of the service.
I was responding specifically to finding indentation errors. Most of the class of errors you mentioned can only be validated by attempting to apply the manifest to a live cluster running the target API version anyway.
Everything you mentioned as a Helm feature is not in fact exclusive to Helm, and can be done either in code using the client libraries, or other deployment tools. For example I've written my own deployment tools that provide "value overlays" by simply merging the in-memory structs in Python or Go code - a manifest is just a data structure. I've also written code that can do ordered deployments with checks at multiple stages, which is both easier to do and more powerful when you write Python/Go code than trying to twist your dependencies to fit Helm's sync wave system.
> The only time an infra engineer would trust the types is if the vendor themself supplied them, or there's a mainstream community effort to keep them up to date
Good news! The Kubernetes project has a documented compatibility strategy (https://kubernetes.io/docs/concepts/overview/kubernetes-api/...) and publishes new client library versions for every release. There's endpoints in the API to interrogate the API's versions and supported fields/features for every resource. Additionally, most API types will accept old versions and automatically convert them to the newer versions, wherever this is possible.
> At the end of the day, the API takes a string, not some protobuf or CORBA or God knows what binary serialized monster dujour...
This is not necessarily correct. Kubernetes API supports JSON, YAML, protobuf or CBOR over the wire, and all become in-memory structs on the server.
No, crossplane types are CRDs so ironically you have to use the `unstructured` package for them instead of the proper typed structs in the core client libraries. (Unless you also generate typed libraries for your CRDs).
> Do you want your agent to burn 10000 tokens fixing indentation bugs every time it touches a helm chart?
If your agent is doing this you need to get a much better agent. It should call `helm lint` to find those errors.
You can import the client library and work with types directly if you like. I've done that for years, it works great.
Banking software is extremely regulated and controlled, both by governments and within the industry itself (one small mistake can wipe out entire institutions within a day:
https://en.wikipedia.org/wiki/Knight_Capital_Group, banks are extremely risk-averse with technology). So likely they were comfortable using agents to _read_ their code but not to write it.
HTTP/2 works differently, you can multiplex and prioritize different data over one TCP connection with HTTP/2. But 60-70% of the web is still HTTP/1 IIRC.
Same. I make a lot of stuff to stratch hyper-personal itches or replace paid software with a narrow solution for my use case, running on my own devices or my home server. I don't post most of it online because I figure anyone else with the same need can generate their own custom solution.
For me it's the combination of:
1. Multimedia. I have a cookbook with photos and videos in my Obsidian, as well as songbooks with musical notation that renders properly.
2. Databases. e.g. for an international vacation I created the itinerary as a "Base" (structured database) that rendered out to a calendar and day-by-day pages. This even included floating itinerary items like "eat X kind of cuisine" to squeeze in on any day, shopping lists for gifts to bring back, as well as all train routes, flight numbers, hotel/ticket confirmation numbers and the like. Then on each day I could journal what we did and see what we still had to do. I was able to share these with everyone on the trip and make sure everyone got to experience their must-see items.
3. You can argue all of the above would also work as a website. But Obsidian makes this work across my phones and tablets too, in a way that I can edit from mobile whenever I need to jot down a quick edit. That's the killer feature.