handruin

Have you also looked at Tildes.net?

You can do this. Click the lock icon and then you can browse around without changing stations.

Perception that they are THE cloud player to use with great reliability and enterprise focus, so people support their protocols and develop their products for AWS and end up with a bit of lock-in. Mid to large enterprise continue to get on the cloud train hype and spend tens, to hundreds of thousands a month on AWS/S3 instance costs and cannot figure out how or why the bill is so expensive. Then they spend internal costs and personal resource time trying to figure out how they spent so much money on AWS. This happens where I work on both the test/dev and also production hosting.

If DO or Linode were an option to consider, we might be able to save so much money but our own customers use and believe in AWS so we develop and test on AWS. It's a bit of a vicious cycle.

Have you seen these remote temperature monitors from sensorpush? They seem to do a decent job and there is an internet gateway device to manage them if you want.

http://www.sensorpush.com/#products

Nope...the argument is more like the shoe manufacture should just include the shoelaces. Shoelaces support the functional operation of the shoe...a purse does not support the operation of shoes. Most people would expect their shoes to come with shoelaces, not a purse.

Thank you for sharing this; I hope more people can see this. Apple gets the credit for this notch when it was the Essential phone that implemented the idea first. At least in the Essential phone their notch was so minimal to just get the camera to fit that it was not very intrusive. Even though I'm not a fan of a notch, this worked fine.

My podcasts are all downloaded with multiple episodes for each podcast and so is a large collection of my Spotify music. I get what you're saying but it isn't that big of an issue with a reasonably modern mobile device and a little customization of the app to do the downloads for you.

This isn't just an American car thing. My past two Japanese vehicles and two German vehicles had SiriusXM built into the radio.

I've had very few buffering issues with Spotify via LTE over the years when compared the constant dropouts from my SiriusXM in my various cars that have had this service. SiriusXM audio quality is also terribly compressed and tinny in addition to the constant drop outs. I've never had a good experience with their product.

Spotify can also download large quantities of music and playlists...so with minimal planing you will have no buffering issues.

The article leaves me with more than a few doubts with this strategy of storing power. One issue that concerns me is the amount of energy that will need to be spent in manufacturing all the concrete and steel drums as well as the amount of pollution this will generate. There will also be the pollution in transporting the drums onto the battery locations. I get that this isn't a unique problem and other forms of "green" power generation also suffer from this such as wind turbines or even photovoltaic panels. Once the drums are onsite there is likely minimal maintenance needed so once the cost of producing is done, there should be a way to figure out how many years or months it would take to offset that.

Thanks for the link. That looks interesting; I'll have to give that a try. When I started reading the link my first thought was Pex from Twitter. I don't know how comparable XAR is to Pex but it's worth a look to compare the two.

I've recently been exploring AWS Lambda in a stack which contained API Gateway + Python Flask under Lambda for a task I was working on. I deployed it using Zappa and its purpose was to be a simple REST frontend for transferring files to S3.

After experimenting with uploads from Lambda to S3 I was noticing that the time to upload a tiny 4MB file changed dramatically when I reconfigured the Lambda function's memory size. At 500MB it took 16 seconds to upload the file which is pretty slow. Once I got past roughly 1500MB of memory, the performance no longer improved and the best I could get was about 8 seconds for the same payload.

None of my tests were controlled or rigorous in any way so take them with a grain of salt...they were just surprising to me that the speed changed dramatically with memory size allocation. I'm new to Lambda so I wasn't ware that memory size is tied to other resource performance. I'm curious if this goes beyond CPU and also changes network bandwidth/performance? The Lambda I deployed did not write data to the temp location that is provided, it streamed directly to S3.

I've since moved on from this implementation and now my Lambda function performs a much simpler task of generating pre-signed S3 URLs. I have noticed something else about Lambda that bothers me a little. If my function remains idle for some period of time and then I invoke it, the amount of time it takes to execute is around 800ms-1000ms. If I perform numerous calls right after, I get billed the minimum of 100ms because the execution time is under that. The part that bothers me is I'm being charged a one-time cost that's about 8x-10x the normal amount because my function has gone idle and cold. I'll have to continue reading to see if this is expected. It's not a huge amount in terms of cost but surprising that I'm paying for AWS to wake up from whatever state it is in.

I came here to say the same. I was not expecting a huge graphic with a cartoon naked ass to show up on my work system.

Tough to say for sure regarding taking attention from the Switch but from what I've seen the Switch is still selling out very quickly from retailers. That makes me believe there is still high demand.

It could be that their virtual console once-released may be in competition for sales of classic games.

Actually...I am doing some of that also.

Don't forget parity drives for availability take away from usable storage.

NAS #1 is 12 x 4TB with 2 drives used for parity.

NAS #2 is 20 x 6TB with 4 drives used for parity.

That takes away roughly 32TB of usable space under zfs. NAS #1 has 40TB usable. NAS #2 has 96TB usable. Total 136TB usable.

The remainder of the drives not accounted in the list above are in workstations for local storage and other random tasks.

I never said I required this much for personal use...I just have it. :)

I started with 12 x 4TB in one NAS and I filled it in a little over 2 years. I just recently built a second NAS with 20 x 6TB to last me hopefully for the next several years.

The other remaining drives unaccounted for are in two workstations for local storage.

I've gone all-in on HGST for personal use because I've seen their results from Backblaze and also have good luck with them so far. I have 14 of their 4TB NAS and 22 of the 6TB NAS.

I had four of the Seagate 3TB drives that are listed in their ratings with high failure rates. All four of mine died in less than 3-years. They were a really disappointing purchase.

Very good point. This would make it easier for me to add to a service or cron job to pull periodically.

I'm interested to know what the pros and cons are of this utility vs using the Google takeout functionality? I like the idea of this project but I don't know what it would gain me over Google's native export? Is it the restoration that's missing from Google's service?

https://takeout.google.com/settings/takeout

I also don't see any app access granted for Pokemon Go under my LG V10 and Google account.