jpdb

Try checking out kpt, it does packages and hydration.

https://kpt.dev/

> I suspect if a Service Mesh is ultimately shown to have broad value, one will make it's way into the K8S core

I'm not so sure. I suspect it'll follow the same roadmap as Gateway API, which it already kind of is with the Service Mesh Interface (https://smi-spec.io/)

I just wrote something extremely similar, but it's only internal right now.

I personally find that the service mesh value-prop is hard to justify for a serverless stack (mostly Cloud Run, but AWS Lambda too probably), and in situations where your services are mostly all in the same language and you can bake the features into libraries that are much easier to import.

Observability is a great example of this. In serverless-land, you're already getting the standard HTTP metrics (ex request count, response codes, latency, etc), tracing, and standard HTTP request logging "for free."

Relatively the same price, I'd say. But there's definitely not they many products out yet so maybe that will change.

I think the biggest difference in price I saw was from my Z-Wave blinds versus Thread / Matter ones. However, the overwhelming majority of the cost for that is the blinds themselves so it's probably not the best comparison.

I currently have a SmartThings Hub and Homeassistant Yellow, but if I were starting over today, I'd be all in on Matter (mostly thread) and avoid ZWave and Zigbee outright. I'm mostly stuck to zwave because of my blinds, but I think I will slowly replace all my smart home related things with Matter.

There's still a few sensors that there don't have a Matter equivalent yet, but I think that'll change soon.

I don't really understand the value of a project like PostgREST.

It feels like you're coupling your application schema to your database schema, which is something you generally want to avoid.

Is this only for niches where you are ok with the db schema being tightly coupled? Do you use specific views to decouple the two schemas? In that scenario it seems like you might eventually get to a point where your view is more complicated than setting up a more traditional application.

> a single Postgres master with replication/standby gets you very far

So does a distributed database. A primary/replica has an ops burden too, and measuring that complexity is subjective.

With primary/replica you still take downtime during failover, you need to make sure you're testing the failover, upgrades aren't zero downtime in a lot of cases, etc.

You're essentially treating your database as a pet and a clustered option is much more cattle vs pet. This saves you time to develop other features (including working on reliability -- the most important feature)

I have the Vantoo T0's as well and would highly recommend. I don't feel like I need a subwoofer either, which saves some room under my desk.

> case studies in where you should add context to error messages

I'd love to see this. I feel like I often default to adding context to my errors, which is probably better than defaulting to not wrapping at all, but would love to know what criteria you use to determine when adding context adds value

Cool project. Love the name.

Hard disagree. The operational overhead of RDBMS and specifically their inherent reliance on a single primary node makes them, in my opinion, a bad place to start your architecture.

I want to be able to treat the servers in my database tier as cattle instead of pets and RDBMSs don't fit this paradigm well. Either NoSQL or NewSQL databases are, in my opinion, a much better place to start.

I feel like RDBMSs being the "default" option is because most people have worked with them in the past and already understand them. It doesn't mean they are the best tool for the job or even the tool most likely to solve the unknown problems you'll encounter in the future.

I think that is a worthwhile test and agree banning things like spam or extremely grotesque content means you aren't a "free speech absolutist." However, banning some speech (such as those mentioned above) wouldn't necessarily put him in the camp of only being interested in his own free speech.

I have SmartThings and while it isn't my favorite platform, it is (was?) nice because it "just works" and is accessible to the family.

Even so, I plan on moving to HomeAssistant where I'll have to setup HTTPS and port-forwarding into my home network for integration with my voice assistant (Google Assistant). It seems like the future of SmartThings is questionable so I would rather migrate, especially with Matter as a standard looking to replace ZigBee and ZWave.

Spot is excess capacity. If there's zero excess capacity, that means there's (probably) also no on-demand capacity as well.

> To combat this we wrote a "runWarm" function that kept the API alive at all times.

This doesn't really work like you'd expect and isn't recommended, as it only helps a particular use-case. The reason is that AWS Lambda will only keep a single instance of your function alive. That means if two requests come in at the same time, you'd see a cold start on one of those invocations.

Instead, you want to look at something like provisioned concurrency.

Pretty much all of AWS and Amazon runs on Dynamodb.

Google has Firestore as one of their approved databases for internal use.

Those are ones I have first hand experience with.

I know from friends that Microsoft runs things on Cosmos.

Netflix is pretty invested in Cassandra.

NUCs are a bit difficult to source right now, but I'd be super interested in coloing ~4 of them + a switch + a nas of some sort in a 1/2U chassis running k3s.

The selinux coloring book is another great example: https://people.redhat.com/duffy/selinux/selinux-coloring-boo...

I'm one of the people who helped build one tiny part of this, and I think the coolest part of Redact is the fact that it makes it possible to clean up your social media history without totally nuking it from orbit. Early on, we thought that most people would use the service once to delete everything, and never touch it again or only use it once every few months or even years. We quickly found that a lot of people want to continue to use social media services and like retaining the contents of their social media and history of their lives, but want to clean up some things that don't reflect their current views or could cause issues today.

I've liked GraphQL the few times I've used it, but I think the standard way of doing pagination with `node`s and `edge`s makes me feel less like I'm working with my data and more some odd abstraction. I think if I used GraphQL more I could get over it, but that aspect always makes me wish for just a bit more.

I used to work at AWS and I have no first hand knowledge in this case, but would guess it's far more likely that the engineering teams figured out a way to run it cheaper than at launch, and passed that savings along to customers.

I've always considered applying to work at Riot; but when I see situations like this employee acting extremely unprofessionally (saying, "I wish I could say it has been a pleasure" is just such a terrible way to conduct yourself as a representative of your company) I'm reminded why I will never apply.

Seeing stuff like this makes me think they've taken almost no steps towards changing their culture that was heavily reported on a few years ago.

Lain catches a lot of flak in anime circles for being "edgy" or "deep for the sake of being deep" in that it tries too hard to be something thought provoking, but lacks any real substance. People still assign what they think the show is trying to say, but because the show is so abstract anything sticks.

I tend to agree with the above point, but it has been quite some time since I watched it. I wonder if a new personal perspective and rapidly changing tech landscape would change how I feel about it today.

Paper money has a lower bound of material value equal to $(toilet paper - utility value for the comfort of toilet paper over a dollar bill) per square inch.

Are you referring to the S3 API? I believe the S3 API is explicitly licensed under Apache.

Disclaimer: I was previously employed by Amazon and currently Google. Opinions are my own, I'm not a lawyer, etc.

> It doesn't make all the other yaml files happen. It doesn't make the yaml files you no longer want happening, stop happening. It doesn't even tell you "these things were created by 'old' yaml files" and should be garbage collected (since it doesn't seem to have a sense of old yaml files).

This is definitely one piece of Kubernetes that is getting a lot of attention recently. The three tools I've been paying attention to are Argo CD[0], Flux[1], and Config Sync[2].

All of these allow you to point your repository to a cluster and sync resources from the repo to the cluster, including deletes.

[0] https://argoproj.github.io/argo-cd/

[1] https://github.com/fluxcd/flux

[2] https://cloud.google.com/kubernetes-engine/docs/add-on/confi...

Disclaimer: I work at GCP, but not on the GKE team. Opinions are my own.

Can we get the title updated to MF DOOM has died?

> Just remember ALL CAPS when you spell the man name

https://youtu.be/noPlIn8TJSQ

This article is extremely dishonest and should be removed. It offers zero proof this is what lead to the compromise. The leaked credentials were reported over a year ago and patched according to FireEye.

There are already comments here from users who presumably haven't read the article and are parroting this as fact.

I used to be complain about the same thing and even asked someone who was head of BD for Serverless at AWS what they recommended, and didn't get an answer to my satisfaction. After working with more and more serverless applications (despite the development pains, the business value was still justified) I realized that local development was difficult because I was coupling my code to the delivery. This is similar to the way you shouldn't couple your code to your database implementation. Instead, you can write a function that takes parameters from elsewhere and call your business logic there. It definitely adds a bit more work, but it alleviates quite a bit of pain that comes with Lambda local development.

Disclaimer: I work at AWS, however not for any service or marketing team. Opinions are my own.

I interact with Jim (obs creator) pretty regularly and he definitely deserves the support. Dude is extremely talented and kind. He puts an insane amount of effort into OBS.