About 6 years ago, Google Fiber buried fiber along several streets that surround my South Durham neighborhood, but I couldn't order it until this year. I had it installed in April and it's been excellent.
The day before my installation appointment, Google Fiber called me to let me know there was a problem with the fiber on my street. They said they'd have to reschedule my installation. I was really disappointed about the delay, expecting I'd have to wait until they fixed the problem on the street to even pick a new date, and that it might be several weeks away. But right there on the call they said it should only take a day to fix, and they could do the installation the day after the original date. I was impressed that they would commit to such a quick fix and reschedule right then.
The installation went smoothly. The equipment installer arrived exactly on time, and finished in the one hour that was scheduled. With Spectrum, I was often given a 3-4 hour window for service, and sometimes they were later than that. Makes you block off a half a day just in case.
The speed and latency are always great. The reliability beats Spectrum, which would go down for minutes to hours when power flickered during storms. I don't think my Google Fiber service has been down for a single second.
I don't have any experience with ZFS, and very little with BTRFS, but the reason I pick XFS is that has "just worked", out of the box, on every Linux distribution I've managed for about 20 years. Back then, it was one of the few choices that didn't have a static inode limit, and it could be grown while mounted. That was a big convenience on file servers when combined with LVM and/or hardware RAID. ZFS sounds hard to manage, I thought BTRFS was still eating peoples' data for a while, and XFS just keeps working fine.
I think it's fair to say a nuclear power plant "uses" the water that it discharges its waste heat into as it flows out into a river or large body of water. If it didn't use that water, it would have to dump its heat somewhere else.
With AWS, the "datacenter" isn't a concept users have to worry about (or can even discover or manage). Each AZ comprises many datacenters, each region comprises many AZs, and AWS makes it easy to deploy most services across multiple AZs in a region. If one AWS datacenter goes down (and this happens occasionally), typically only one AZ in the region is affected.
That's one heck of an edge case! How does fsck manage to completely confuse filesystem metadata and data like this? Surely this is only if there's corruption in the (outer) filesystem, right?
I re-read your comment and you do say "same" prefixes (I think I read it as "shared"), which AWS hasn't changed the behavior of (AFAIK). You're right that objects with the exact same prefix are still routed to the same shard (set?) and have that throughput limit.
P.S.: In a few projects I've built prefixes using timestamps, but not at the very beginning, and worried that they weren't getting sharded out. The change I linked to fixes that problem.
IPv6 works fine. It's all over my house, my mobile devices use it all the time (they're probably IPv6-only over LTE at this point), and I don't have any problems when I occasionally have to type in an IPv6 address. I don't see how you'll wrench IPv6 out of the billions (?) of devices using it and make them use anything other than IPv4 at this point.
In my testing (years ago, don't have the data) there was no detectable difference between PKs of the uuid and bigint types in my application, but there was a difference between uuid and int (int was faster). uuid is 16 bytes, bigint is 8 bytes, int is 4 bytes, so at some scale there will be a performance difference.
This used to be the case, but it's not true any more.
For example, previously Amazon S3 performance guidelines recommended randomizing prefix naming with hashed characters to optimize performance for frequent data retrievals. You no longer have to randomize prefix naming for performance, and can use sequential date-based naming for your prefixes.
I have a couple of Reolink PoE cameras that live on their own VLAN without internet access except for NTP. I can access them through the LAN, and outside the house using a Wireguard VPN.
That's right. I bought the book for a few dollars, not an AS/400 system, though I'd probably find a decorative use for one if I found one that cheap. I look at eBay and Craigslist every so often for cheap used mainframes (or at least the front doors) that I could turn into a neat garage fridge.
Thanks for all those technical details! For anyone else who'd like a broader tour around the AS/400, I can recommend "Inside the AS/400: Second Edition" by Frank Soltis. I bought it used for just a few dollars and really enjoyed learning about the evolution of the platform from one of its original designers, even though I doubt I'll ever put my hands on one directly.
I doubt the amount of dextrose (anti-caking agent) you consume with table salt could ever be nutritionally significant. Have you seen other sugars added to salt? I never have.
I don't have specific numbers, but I think each AZ comprises many data centers. us-east-1 is a very large region, and I don't think any single AZ fits in one building.
There's a lot of uncharitable talk in this thread, where comments like yours assume bad intent on behalf of businesses who find GDPR compliance challenging. It's a giant body of regulatory law, of course it's complicated! The GDPR probably _isn't_ hard to deal with if you don't actually care about privacy; it's easy to just not follow the law and hope you don't get caught. But if your company respects individual privacy, and collects personal data only with a lawful basis, and needs to make assurances to its customers that all the regulations are being followed, there's a lot of work you have to do to demonstrate compliance, and many specifics (for example, with regards to personal data erasure in backups and archives) are completely unspecified. How uncomplicated is that issue?
Having worked in a US health tech start-up (and done some compliance work there), and now working with GDPR as a US company, I'm similarly frustrated with how imprecisely the regulations are worded. US health information privacy laws are much easier to interpret and follow. Large, important parts of GDPR compliance hinge on wording like "the processing is not occasional." "Occasional" is not defined in the regulations, and different countries' advisory bodies have completely opposite interpretations about what it means.
I'm using Ubuntu 21.04 with Wayland and, yes, screen sharing works in Google Meet, Slack, and Zoom. I haven't tried Teams in a while, so I don't know about that.
I haven't been in a position where I needed to finance work on my home, but I have wanted a safe and easy way to pay individual contractors. Some of them prefer cash or paper checks (and their tax liabilities are their business), but an electronic payment is better for me. I'd feel better if the payment platform offered me a bit of protection (arbitration? just a standard contract?) if there was a dispute over the quality of the work. I think there's definitely a space for a trade payments platform.
I understand the desire to avoid paying tax by taking cash, but is it common that a tradesperson is paying 50% income tax? I only have a US resident's perspective, but that rate seems very high.
We're definitely not fans of Joe, and were a little concerned about the association early on, but we've talked with hundreds of potential customers since we started and it hasn't come up yet. A lot of them get the RPO pun quickly, though!
Unfortunately, we aren't able to read users' passwords from Cognito user pools, so they do have to reset them in the recovery environment. We'd love to see an AWS API for exporting user secrets from user pools. We'd add support for that really quick.
The experience is better for user pools that integrate with external identity providers, like SAML, since the IdP metadata can be fully replicated into the other region ahead of time.
Before this update, S3 provided "read-after-write" consistency for object creation at a unique path[0] with PUT and subsequent GET operations. Replacement wasn't consistent. So I think you could have worked out some kind of atomic pattern with S3 objects, using new keys for each state change.
Putting the name of the cheese (style) he's making in the thumbnails is his usual format. I've watched a dozen or more of his cheese-making videos. I don't think his Grana Padano thumbnail differs in any significant way.
I wasn't following the Python 2-to-3 transition that closely, but I don't think Python ever forced anyone to use UTF-16. On Unix platforms (the only place I've used Python for 10 years) the strings are UTF-8 internally. On Windows maybe it's UTF-16, I don't know, but most programmers don't need to know or care. They just bytes(my_string, 'utf-8') to encode it as bytes.
I only watch YouTube on my PS4 using Google's app, so I don't think SponsorBlock is an option there. I was really happy with Red/Premium in the early days because I felt like I was getting a great deal for the price. Apparently there aren't enough subscribers, or Google doesn't share enough revenue with creators, or some combination of that and other things--but the experience is getting worse every week. I guess it was good while it lasted.