Kid_Thunder

Actually, it highlights the importance of a proper distributed backup strategy and disaster recovery plan.

Uh, yeah, that’s why I said

it is good practice and frankly refreshing to hear that a company actually backed up away from their primary cloud infrastructure

The same can probably happen on AWS, Azure, any data center really

Sure, if you colocate in another datacenter and it isn’t your own, they aren’t backing your data up without some sort of other agreement and configuration. I’m not sure about AWS but Azure actually has offline geographically separate backup options.

And the crazy part is that it sounds like Google didn’t have backups of this data after the account was deleted. The only reason they were able to restore the data was because UniSuper had a backup on another provider.

This should make anyone really think hard about the situation before using Google’s cloud. Sure, it is good practice and frankly refreshing to hear that a company actually backed up away from their primary cloud infrastructure but I’m surprised Google themselves do not keep backups for awhile after an account is deleted.

I was trying to find the old Level 3 blog post but didn’t because I believe they basically said that Comcast needed to upgrade its infrastructure and never did. Netflix was the cashcow they saw to essentially make them pay for it. As a Comcast customer, I see it as charging the customer twice – first for the Internet service for the content and again because Netflix is going to pass that extra cost onto you (and everyone else who isn’t a Comcast customer).

You’re right on about CDNs and edge / egress/ingress PoPs. It also keeps it cheaper for the likes of Netflix/Amazon/etc. in the long run with the benefits of adding more availability.

I found this wikipedia article about backbones and peering but it really isn’t that great but in the results it also came up with this pretty good presentation from Carnegi Mellon. I was only going to browser a few of the slides but the information isn’t really all that much and the illustrations are good. I think Prof. Nace did an excellent job here. Much better than I would have.

The problem historically isn’t that streaming services are paying for fast lanes but that they have to pay not to be throttled below normal traffic. In other words, they have to pay more to be treated like other traffic.

Even crazier is remember that there are actual peering agreements between folks like cogentco, Level 3, comcast, Hurricane Electric, AT&T, etc. What comcast did that caused the spotlight was to bypass their peering agreement with Level 3 and went direct to their end customer (netflix) and told them they’d specifically throttle them if they didn’t pay a premium which also undermined Level3’s peering agreement with Comcast.

Peering agreements are basically like “I’ll route your traffic, if you route my traffic” and that’s how the Internet works.

Why does it feel like EA tries really hard to kill off franchises with a loyal fanbase by constantly playing limbo under the lowering bar?

Samsung signed a deal so that they can use the Jibe API to be a part of E2E when using RCS.

Since I’m sure there’s Internet where you’re at, you can take a look from Verizon’s RCS roll out on messages+ in 2021 to Samsung’s S9, prior to relying on Google Jibe. Verizon did eventually switch to use Jibe for their entire RCS implementation now instead of relying on their own infrastructure as did T-Mobile.

Well sure. You’ve got to trust that Jibe isn’t man in the middling the key exchanges but regardless, it doesn’t change what I said.

Not true. Both Samsung and Verizon messages uses RCS, so long as your carrier has implemented RCS.

They are also the only RCS supplier on Android. A random messaging app can’t simply add RCS messaging functionality.

You are correct that an app can’t directly implement RCS but it can support it. RCS is implemented by the carrier, not by Google or any other text application.

RCS is an open standard that any carrier can implement to replace SMS/MMS. The only thing special that Google does is on top of RCS is provides E2E via its own servers for handling messaging. The E2E isn’t a part of RCS, though it should be IMO. Regardless, Google doesn’t ‘own’ the Android implementation because it isn’t a part of Android, other than it can support the carrier’s implementation of RCS.

deleted by creator

It looks like to me that its set up purposefully to obfuscate its structure. I’d also assume the reason for the loan for 15% of shares was so the parent essentially isn’t really just a sole owner to protect them from liability.

The best part is when the business customers had to use an AI chatbot for support which was as helpful as the AI Adbot.

Right now the closest we have to that is running ampere clusters. I’m saying that because it is going to be some years before any phone GPU/CPU is going to be able to effectively run a decent AI model. I don’t doubt there will be some sort of marketing for ‘boosting’ AI via your phone CPU/GPU but it isn’t going to do much more than be a marketing ploy.

It is far more likely that it will still continue to be offloaded to the cloud. There is going to be much more market motivation to continue to put your data on the cloud instead of off of it.

It’s already here. I run AI models via my GPU with training data from various sources for both searching/GPT-like chat and images. You can basically point-and-click and do this with GPT4All which integrates a chat client and let’s you just select some popular AI models without knowing how to really do anything or use the CLI. It basically gives you a ChatGPT experience offline using your GPU if it has enough VRAM or CPU if it doesn’t for whatever particular model you’re using. It doesn’t do images I don’t think but there are other projects out there that simplify doing it using your own stuff.

For the big products, I think Google Assistant will be next followed by barely doing anything further with Android Auto until it dies a few years after GAS starts getting pushed out while it probably either won’t or will stop supporting ‘legacy’ Android Auto apps, so AA dies ‘because developers aren’t supporting apps anymore – totally not our fault and we’re sorry to see this happen.’

Former Googlers have always said that the big issue with sustaining products at Google is that it is highly competitive and Google rewards new products, not sustaining current products. So, most people want to continuously join/form teams for new products leaving little resources for current products. This has been the way since Google started becoming a large company – so decades now.

This makes sense as to why Google puts out applications that seemingly do the same thing as something else but ever so slightly different and why there are sometimes cool new products that die on the vine years later and if there was no slightly different thing available it just dies or if there is then there is a half-assed migration.

In the Reddit AMA the Google Home team answered a few questions and only the very few softball ones. One interesting comment they made though is that because of the Nest products and generally new products, they believe it is a challenge to support the older hardware, including integrating Google and Nest hardware, so basically you get features removed to make it all work. Of course, there was the promise and supposed internal roadmap that puts these features back eventually, but we’ve seen that kind of promise over and over from Google and it rarely happens. They are trying to replace Assistant with their Gemini AI which you can do now but it comes with even less features (but parity is coming – they promise!..one day!). Is that parity with current Assistant which seems to be supporting less and less and working worse?

Google is losing a lot of consumer trust in products I think and it’s going to get worse for them as this trickles to the general consumer-base.

This list is so bad, it has to be a troll.

I accidentally overwrote /etc/passwd once and I allowed /boot to run out of space during a kernal update and I created a local user with the same user that was also on the realm/domain that I had joined and various bash script issues.
Some stuff I’ve had to fix that someone else did:

• named a file rm -rf
• rm -rf /bin instead of ./bin – Also the fact that they had sudo was crazy and also I guess this was the second time
• chmod -R 777 /
• Various software bugs running swap out of space or hitting the inode limit by creating files over and over again with a timestamp in the filename and having to remove all of them because there was no backup to the OS
• Someone disabled SELinux because something wasn’t working but didn’t tell anyone – ugh
• Compiled java because they googled some issue and followed some old tutorial without understanding anything instead of using alternatives and symlinked the old java from /bin to /home/theiruser/java – had sudo because he was a Windows domain admin.
• Cybersecurity guy didn’t know what some VMs did so he turned them off and figured he’d find out if/when someone complained. Caused a massive core services outage.
• Same Cybersecurity guy deleted a bunch of data because he wanted to see how the sysadmins would respond and witness backup restorations. He did not inform anyone.
• Cybersecurity guy above still has Domain Admin and sudo everywhere. I would have personally removed his privileged access regardless of what ‘CyberSecurity’ management thought but I was leaving for a new job by then anyway so I figured I’d just let them eventually lie in the bed they made.

There’s more but I don’t want to keep going because it is Sunday and I don’t want to ruin it.

You can use Gnome Boxes to give you a front-end for KVM/qemu like VB. With the spice-webdavd package, you can share files similarly to the guest or send files directly to it.

As far as Samba goes, it is just a FOSS implementation of Microsoft’s SMB. Just like with Windows, you’ll have to open Explorer to the IP/Hostname of your Samba server or I guess have both join the same workgroup with the same name on the same subnet.