BaconPackets

I'll need to look at the underlying data, but it seems that the job "classification/category" should be more important than the raw number. A boost in lower paid/service industry jobs does not mean that there wasn't a loss in a category where AI can be more easily dropped into existing businesses.

Data : https://www.bls.gov/news.release/pdf/empsit.pdf

This is meaningless without context.

This is such a weird redirect. Biden seems to have pardoned a large amount of low level marijuana offenders.

So yes, there is a difference between what Trump is doing and what Biden is doing.

There is already a couple of options

https://github.com/multycloud/multy

But a multicloud wrapper creates a lot of abstractions.

It’s a strange article. Really focused around gas prices and little about food/home prices.

People can’t eat gas. The impact of a 5% to 10% increase in basic food prices is extreme on most income levels. Especially when you consider families with children.

I would be really curious to drill down into one of these problems. Is super precise really the solution?

That is my feeling as well. I am not sure how this is more than someone rambling and yelling at the cloud.

This is a very competitive space. You don't hear about a specific leader because there are so many pretty good options.

They mostly do everything you describe and more.

Cloudability is one.

I'm really curious at how everyone is approaching scalability/reliability/redundancy at scale.

We are in the midst of a 10k VM migration to AWS and GCP and it's definitely challenging.

Balancing the speed of the migration itself VS not ending up lift and shiftong workloads is difficult.

Ah yes, I knew his name sounded familiar. He's the one proposing that weird mix of NFT and cryptocurrency stuff with Tea.

We recently did a quick POC with py-cui for a TUI app. It worked pretty well but you quickly see the limits.

This looks really interesting and could be a fun way to get into the Go landscape!

The root cause is REALLY surprising. If it's really an unrelated change to the NAT/STUN relay server, it means that there was a pretty broad lack of change management framework.

To be fair, this is well covered with most enterprise scale Finops for CSP.

It might be more expensive to run but you have savings in terms of time to deployment, orchestration and the overall maturity of the cloud itself.

Managing bare metal at scale is challenging.

:shrug: That's fine, I would always rather have a conversation. Thanks for your time!

Thanks! That gives me a bit more context.

I'm currently reading up on this, but I'm struggling to match a use case.

It's not Openstack. It's not VMware. It's not kubernetes. It's not proxmox. It's not Xen. It's not Anthos. It's not GCDE. It's not Outposts.

So who and what is it for? Where is the use case that none of these other products fit the bill?

Especially for an on premise use case.

That is interesting. Red Hat is a major player within the telecom industry. I do wonder how support will work for Russian Telcos running VNF on Openstack.

I assume that all contracts have some force majeure actions baked in.

That's interesting. I'm not sure where the technicality resides. If that situation is the case, I assume that it would be quite catastrophic for anyone using non-Russian services for IT.

Isn't there a very high chance that western militaries are sharing high resolution satellite photos with the Ukrainian military?

I understand these pictures not being public.

With the nature of the conflict, I assume that some third letters agencies have 24/7 coverage of the entire country.

What do you mean by unable to pay? Would it not just be more expensive? Assuming the banks will convert your transactions when you pay.

The Russian banks seem to have stockpiled currency, so I assume they will be able to keep the loop going.

Oryx did fantastic work with tracking the military hardware during the Syrian civil war. Really interested to read this.

The only way I would be comfortable deploying Openstack in a large scale enterprise structure is a pre-packaged solution from Red Hat/Canonical.

There is just so much that can go wrong and so much that goes into maintaining the life cycle.

Frankly, at this point in time of the industry, your business case better drive the need for on premise computing. If it doesnt --> AWS/gcp/azure

Software longevity is something that I have bene thinking about for a little bit.

At $dayjob, we use Openstack, an open source cloud infrastructure project.

It's a pretty complicated set of projects that interact to each other in order to provide multi-tenancy for virtual machines at scale.

It was initially all the rage, before the cloud starting really picking up steam.

So now, you have a massive project that is slowly losing traction, but also relying on that notoriety to gain developers.

So, I think Linus point is quite valid. These small, low risk, low value patches are essential in having a healthy community around a product.

They help easing your way into a codebase, developpement flow and all the other idiosyncrasies of established tech circles.

I'm surprised that you had that much placement on a single compute.

I do believe there are ways to prevent that compute failure domain at the VM creation with placementgroups

I keep trying to have a use case for eBPF within non kubernetes infra and haven't a good need so far.

Has anyone played around with it and found a corner where is it was useful to have?

Anyone knows dev working within that industry? Any insight in the rationalization of creating tools to essentially spy on the whole wide world?

Always curious to see how we can rationalize these kind of purpose in life.

It's mind boggling that selling VPN services became a thing. Was I the NSA or any state level actor, selling a VPN service as a front seems the best thing to do to cast a pretty wide net.

It's shiny Pokemons cards, but worse somehow.

Nice! Thank you, much better than the Wired piece.