> In 2017, we launched AWS DeepLens to make AI & ML more accessible to developers of all skill levels. With your help, our portfolio of products and services has grown to include new tools for developers to get hands on with AI & ML - including AWS DeepRacer, Amazon SageMaker Studio Lab, Amazon Rekognition, AWS Panorama, and more. Today, we are letting you know that we are retiring AWS DeepLens.

> What this means for you:

> Starting January 31, 2024, you will no longer be able to access AWS DeepLens through the AWS management console, manage DeepLens devices, or access any projects you have created. Until then, you can continue to work on projects and export those you would like to keep by using the step-by-step guide in the AWS DeepLens FAQ. We encourage you to recycle your AWS DeepLens device through the Amazon Recycling Program– Amazon will cover the costs associated with shipping and recycling.

If the layoffs affecting much of Amazon's device division is any indication of broader trends then I wonder if we will soon be under a tsunami of bricked devices as the cloud counterparts are retired. The detritus from software shutting down has historically had minimal impact in the real world. Doing the same with millions of IoT devices seems like such a waste.

Comments URL: https://news.ycombinator.com/item?id=34596419

Points: 5

# Comments: 3

> an M/M/1 queue represents the queue length in a system having a single server, where arrivals are determined by a Poisson process...

So the arrival times are not arriving at any fixed rate, but according to a Poisson distribution. In the article he did reference this fact right before the first plot:

> (For the wonks: I used a Poisson arrival process and exponentially distributed processing times)

And then finally, he answered this question more directly in the comments to the article:

> What’s to prevent the system from bouncing between “1 task in processor & 1 task in queue” and “1 task in processor & 2 tasks in queue” while maintaining 100% utilization?

> Nothing! That could totally happen in a queueing system. However, the arrival process would need to be tuned quite precisely to the processing rate. You would need to watch the status of the processor and, when a task finishes, only then insert a new task into the queue. But this implies a shell game: if you always have a task ready to put into the queue when it needs to be padded back out, then isn’t that task in a sense already “queued”?

> Instead, in queueing theory we usually assume a random arrival process: sometimes a minute may pass between arrivals into the queue; sometimes only a second. So the system can’t bounce for arbitrarily long between 1-in-queue and 2-in-queue states. Eventually, one of two things will randomly occur:

> 1. From the 1-in-queue state, the active task finishes processing before a new task arrives, bringing queue size to 0.

> 2. From the 2-in-queue state, a new task arrives in the queue before the active task finishes, causing the queue size to grow to 3.

[0]: https://en.wikipedia.org/wiki/M/M/1_queue

> What’s to prevent the system from bouncing between “1 task in processor & 1 task in queue” and “1 task in processor & 2 tasks in queue” while maintaining 100% utilization?

> Nothing! That could totally happen in a queueing system. However, the arrival process would need to be tuned quite precisely to the processing rate. You would need to watch the status of the processor and, when a task finishes, only then insert a new task into the queue. But this implies a shell game: if you always have a task ready to put into the queue when it needs to be padded back out, then isn’t that task in a sense already “queued”?

> Instead, in queueing theory we usually assume a random arrival process: sometimes a minute may pass between arrivals into the queue; sometimes only a second. So the system can’t bounce for arbitrarily long between 1-in-queue and 2-in-queue states. Eventually, one of two things will randomly occur:

> 1. From the 1-in-queue state, the active task finishes processing before a new task arrives, bringing queue size to 0.

> 2. From the 2-in-queue state, a new task arrives in the queue before the active task finishes, causing the queue size to grow to 3.

Comments URL: https://news.ycombinator.com/item?id=25402558

Points: 1

# Comments: 0

https://github.com/seanfisher/codenames

I've been working on an online Codenames clone as a side project for virtual get-togethers. It is live and playable[0] and requires 4+ players. I'm planning on open-sourcing it as soon as I find the time. It's been a good excuse to practice some Vue.js and Websocket communication and a lot of fun!

[0] http://codenames.seafish.io

Those poor research assistants. Imagine counting hundreds of dandelion bristles every day. Probably still not possible with AI/image recognition either.