anderiv

My word I’ve been looking for a self-hosted alternative to Dead Man’s Snitch for ages. Thank you for this!

Yes, we actually considered that. Unfortunately in our use case, there were many 2.4GHz-only IOT-type devices that needed to be on the network, so we couldn't turn off 2.4GHz. It helped a bit when we turned down the 2.4GHz Tx power - that seemed to encourage more devices to jump over to 6GHz, but even that didn't solve the problems altogether.

I'm not an RF design engineer, but for this type of equipment, I do feel like there's some truth to "you get what you pay for". It's plain to me that the Ruckus APs have superior RF front-ends that are better able to deal with the noise. They're more expensive than Ubnt for sure, but that extra cost was very much worth it for us, to avoid the frequent disconnects that the users were having to deal with.

For the cost, I'd agree that Ubnt gear is quite good. I use it at home, and rarely have any problems.

That said, I'd like to provide one caveat: In my experience, they tend to not do great in very noisy RF environments. Twice now I've deployed Unifi APs in offices with RF spectra similar to what the OP has going on, and we had nothing but problems. In each case, we ripped out the Ubnt gear, replaced with equivalent Ruckus APs (with their cloud controller) and haven't had a single problem.

I admit this is not a large sample size, but thought it worth mentioning.

Yes, absolutely. Good point.

HIPAA compliance doesn't mean anything unless they're willing to sign a BAA with their customers' organizations. Perhaps they're signing BAAs now, but in the recent past (~6 months ago), I asked and they weren't signing them.

While their mail service does have a remarkable track record for uptime, that same record is not shared by many of their other services.

I admin a number of GSuite accounts, and we experience fairly frequent (~monthly) periods of strange behavior with Hangouts/Meet, and Google Drive.

Fortunately Google is very good about providing updates via email to administrators as they're working through an issue.

Yes, it does. If you read through the researcher's post, they have an encrypted volume (VeraCrypt-style) which they mount on an otherwise unencrypted filesystem. Data can leak from inside the encrypted volume, to the cache location outside the encrypted volume.

If you're using Filevault2, the entire hard disk is encrypted, including the cache location.

It should be noted that using FDE software like the built-in Filevault2 mitigates this leak.

Is Jane user ready for the job? Of course not.

Good thing she doesn’t have to be. Fortunately nearly all consumer-grade routers ship with sane defaults, and make it difficult (if possible at all) to change the settings such that the security of the network is severely compromised.

This trope needs to die. Just because a device has a publicly-routable IP does not mean that it’s freely-accessible. That’s why we have stateful firewalls.

There are millions of IPv4 systems at large enterprises and educational institutions that have public addresses, and do you think they’re accessible from the internet? Didn’t think so. They’re behind a default-deny stateful firewall, very similar in function to the stateful firewall that’s present on every single consumer router you can buy.

NAT is a hack that breaks things, and imposes un-needed performance bottlenecks.

It sounds like you’ve already resolved this, but for the benefit of any others that stumble upon this, my solution for deletion of a large bucket is to set a lifetime rule with a short TTL, after which the objects are deleted.

Set that rule, and come back to a beautifully empty bucket 24 hours later, after Amazon’s gnomes have takes care of the issue for you.

The ROI on that seems pretty bleak from a business perspective. Without paying customers’ usage to bankroll the buildout, I find it highly doubtful that any carrier would agree to emergency-use only stations.

I’m fairly certain that Sonos allows multiple streaming accounts for each provider. I currently have three Apple Music accounts registered on my Sonos, and have had multiple Spotify accounts registered in the past.

Netflix doesn’t stream from AWS. Rather, they’ve built their own video CDN[1] with PoPs all over the globe. All of their user-facing streaming happens from their CDN. Their AWS infrastructure is used for billing, transcoding, playlists, etc. Also, they perform some seeding of the CDN from within AWS, but the seed boxes themselves can seed each other as well.

All in all, they clearly do push huge amounts of data out of AWS, but that data account for a very small percentage of the total data that gets pushed out to clients via their CDN.

[1] https://openconnect.netflix.com/en/

Many companies claim HIPAA compliance. That doesn't mean much, though, unless they're willing to sign a BAA with their customers. I don't have direct experience with this and our Slack usage, but I'm guessing this is where the disconnect is.

The pitcher does get to choose what to throw. The catcher signs, then the pitcher either shakes his head "no" or winds up for the pitch. If "no", the catcher chooses another pitch until they agree.

There is precedent for an annual fee: they charge one in addition to the purchase price for their Chromebox for Meetings device as well.

RAM vs. Flash storage. You're comparing apples and oranges here.

  $ whois datamantle.com | grep "Name Server"
     Name Server: NS1.DREAMHOST.COM
     Name Server: NS2.DREAMHOST.COM
     Name Server: NS3.DREAMHOST.COM

Hrm...using dreamhost for their nameservers. Interesting choice.

  $ whois $(dig +short datamantle.com) | grep OrgName
  OrgName:        Google Inc.

Not dogfooding their own service? I think I'll pass.

I'll echo the pfSense recommendation. One correction, though: pfSense is built upon FreeBSD, not linux.

The Netgate RCC-DFF 2220 is available[1] right now, and performs very well as a BSD router. It's not ARM, but it is an embedded system/SBC. I use it with pfSense, but it will run vanilla FreeBSD as well of course.

[1] http://store.netgate.com/ADI/RCC-DFF-2220.aspx

One of my most memorable moments in amateur radio was making a JT65 contact - 1 watt, from the north-central US to the island of Reunion, roughly 10k Kilometers.

And that was on a very ad-hoc wire antenna.

Weather Underground makes nearly all climatological data available in easy-to-consume formats (csv mostly). Using your rainfall example, here's how I'd get a listing of rainfall by day for the month of September, from my local National Weather Service monitoring site:

  $ curl -s "http://www.wunderground.com/history/airport/KMSP/2015/09/31/MonthlyHistory.html?format=1" | grep -v Precip | cut -d "," -f 20

DJB was not arguing that IPv6 would never happen. He was arguing that there are some significant barriers that need to be overcome before meaningful adoption will occur.

I'd argue that many, if not all of the issues with v6 back in 2002 have been resolved, and that v6 adoption is accelerating, both on eyeball networks as well as on public-facing internet services.

On SE, you can delete your identifiable information, turning your username into one of the generic "userXXXXXX" names. All of the content you've produced remains, though.

If you ask, you can request from your AWS account rep to sign an NDA, after which you can get insights into what features are upcoming.

Water is one of the by-products of the combustion reaction, regardless of what fuel is used.

Well the #1 thing for me is that the majority of IPsec functions are in the kernel and don't require that a userland daemon be running (which OpenVPN requires). Beyond that, I've just found that, while a bit more arduous to configure initially, performance is far superior and stability is better than OpenVPN.

Beyond that, pretty much every router out there supports IPsec, so if you're needing to integrate with other non-pfsense hardware, IPSec is often your only option.

Curious why you chose OpenVPN for your site-to-site links. I use it extensively for mobile VPN users, but for an "infrastructure" VPN, I use IPsec, which I find to be a much superior solution for that use case than OpenVPN.

Here's my take on it:

One of the main selling points for ZFS is the end-to-end cryptographic verification of file contents as well as all metadata. Everything in ZFS is hashed, and verified during reads. Without ECC RAM, your hashes are vulnerable to corruption due to bits being erroneously flipped in RAM. If this happens with non-ECC RAM, you're never going to know, and it will cause corruption. With ECC RAM, these events are not only detectable, but also fixable.

Regarding ZFS "requiring a huge amount of RAM". Most of this comes into play if you have dedup turned on. Then you really need a lot of RAM. Without dedup enabled, and if you're OK with mediocre performance, you can get by just fine with a "normal" amount of RAM. It's well-known that filesystem performance increases with more RAM - this is not something that is unique to ZFS.