Bitter that you’re not able to use new features much? Reap what you sow.

It is unreasonable to expect platforms to open up everything to be ripped out and swapped for their competitors.

I expect platforms get more and more cautious as to what they release into unfavorable regulatory environments that offer only marginal economical benefits.

On purchasing servers; I don’t know about Google specifically, but most media partners I’ve worked with doesn’t have global acquisition as an option for hardwares — not because they don’t have the purchase power/volume, but rather the vendors have region specific distributors with their own sales teams and pricing. Even if you have the personal contacts of VPs high up the chain, someone from IBM China cannot even sell to companies in Canada, and vice versa, for example.

On people side of things… With YouTube specifically, you’re also not only dealing with their own DC but getting their hardware into local ISPs centres. Logistics around that is not something cheap remote labor can arrange, need actual boots on the ground to facilitate.

Ad sales is also something that’s kind of localized. YouTube has American teams selling American creator inventories for example. Not something that’s outsourced out.

So yea… Although from the outset it’s all just “YouTube.com”, there’s actually a lot of localized touch points that creates different costs to provide service in different regions.

Without violating my NDA with media companies (YouTube being one of them, incidentally), all I can tell you is you’re wrong about these. I’ve been in this exact sector for over a decade and the operating expenses are much higher comparatively speaking, and the objectives are different depending on region.

If you’re so inclined to pay the discounted rate, make the narrative work so they have no way of flagging you. Otherwise don’t be surprised if you’re asked to pay local rates.

I can’t help but to wonder if they’ve secured it enough such that children do not climb the exterior… 12M is not a short drop and even with rubber flooring, a fall from that height can really injure the kids (whom incidentally are also made of rubber).

I understand the reason; if they join forces, they’ve got a higher probability of winning against the NDP… but look no further than just south of the border and it’s clear the us-vs-them two-party system draws out the worst polarizing side of people. We really should stride for at least three parties so we can come up with fitting solutions to problems as opposed to “I get what I want and you go pound sand”.

Service provider must acquire hardwares for the data centre at local vendor pricing.

Service provider must hire someone local to work in your local data centre.

Service providers need to pay local electricity and bandwidth rates.

List goes on. Just because you don’t interface with the local aspects of business doesn’t mean they don’t exist and add extra costs.

If you want to pay lower rate, as I stated earlier, make your narrative work: use local payment methods, billing address and use the service locally to the locality you’re paying in. Then they’ve got nothing to argue against you as you’re using services in that lower cost region.

Operation costs differently in different regions. Advertising spend differs in different regions. You’ve moved from a region with cheap operating expenses and no ad spend to another region with more expensive operating expenses and higher ad spend. Congratulations on your move, now the cost to provide you service is different, and you’d need to pay more to cover the operating expenses + expected margin.

Alternatively, procure a local credit card (I.e. the same one you used back home), billing address (i.e the last place back home), and always do everything through a VPN back home. Then you’re at least using services from where the operating expense reflects the pricing.

This is just business, and should be expected. Food is dirt cheap back in Asia, they’re more expensive here in North America. Like it or not, if I’m living here, I need to pay the prices here. If I don’t want to pay the prices here, I can move back to Asia.

I hope Apple’s sources are better than Google’s sources, as there could be dangerous ramifications.

I already answered this. Please read better.

Judging by the community response here… no, you have not, please write better.

I won’t bother replying anymore.

Apple offers first party E2EE messaging for their clients, via iMessage.

As part of China’s certification requirements, Apple has been tasked to support RCS, which, per the spec, does not have E2EE feature.

I’ll say this again: RCS does not support E2EE.

If that’s not registering: RCS does not support E2EE.

Come to the think of it, it would actually be surprising if China is mandating an E2EE capable implementation, but I digress.

In order to comply with this requirement, Apple implemented RCS per the specs of RCS. Again, RCS does not support E2EE. There is no specification of RCS that supports E2EE at this time.

Google runs a proprietary system that they’ve built based off of RCS, but is not RCS. This proprietary protocol, which is not RCS, has custom extensions of their own to offer E2EE. Apple is under zero obligation to implement against this, because this is not RCS. In fact, as demonstrated, even other Android systems don’t do this. They use the carrier RCS, which while fragmented and incomplete, consistently does not have E2EE, because, again, RCS does not support E2EE.

There are plenty of cross platform E2EE solutions available: Matrix, Signal, and WhatsApp, are a few major players that popped to mind. I’m sure there are plenty of others that I didn’t call out. They are cross platform which means they already exist on both iOS and Android platforms.

Neither Apple nor Google have any reason to implement those protocols, as, again, they already exist on platform.

How is Apple not implementing Google’s proprietary extension malicious compliance as you called it?

COPPA is pretty straight forward — the tl;dr is that websites are not allowed to collect personal info from children under age of 13.

If TikTok have users under the age of 13, and they’re profiling those users the same as they are with adult users (adult users of TikTok? This sounds so weird and foreign to me; I must be too old), then they’re in hot water. I don’t see how there’s any minority report style of thought crime going on here. It’s pretty cut and dry…

OP Currently has in their possession 2 drives.

OP has confirmed they’re 12TB each, and in total there is 19TB of data across the two drives.

Assuming there is only one partition, each one might look something like this:

Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 12345678-9abc-def0-1234-56789abcdef0

Device         Start        End            Sectors        Size      Type
/dev/sda1      2048         23437499966    23437497919    12.0T     Linux filesystem

OP wants to buy a new drive (also 12TB) and make a RAID5 array without losing existing data. Kind of madness, but it is achievable. OP buys a new drive, and set it up as such:

Device         Start        End            Sectors        Size      Type
/dev/sdc1      2048         3906252047     3906250000     2.0T      Linux RAID

Unallocated space:
3906252048      23437500000   19531247953    10.0T

Then, OP must shrink the existing partition to something smaller, say 10TB for example, and then make use of the rest of the space as part of their RAID5 :

Device         Start        End            Sectors        Size      Type
/dev/sda1      2048         19531250000    19531247953    10.0T     Linux filesystem
/dev/sda2      19531250001  23437499999    3906250000     2.0T      Linux RAID

Now with the 3x 2TB partitions, they can create their RAID5 initially:

sudo mdadm --create --verbose /dev/md0 --level=5 --raid-devices=3 /dev/sda2 /dev/sdb2 /dev/sdc1

Make ext4 partition on md0, copy 4TB of data (2TB from sda1 and 2TB from sdb1) into it, verify RAID5 working properly. Once OP is happy with the data on md0, they can delete the copied data from sda1 and sdb1, shrink the filesystem there (resize2fs), expand sda2 and sdb2, expand the sdc1, and resize the raid (mdadm --grow ...)

Rinse and repeat, at the end of the process, they’d end up having all their data in the newly created md0, which is a RAID5 volume spanning across all three disks.

Hope this is clear enough and that there is no more disconnect.

deleted by creator

Fun story but I’m most impressed with the earbud part of the story. WOW. Absolutely amazing and unexpected.

This is smart! Should help reduce the number of loops they’d need to go through and could reduce the stress on the older drives.

I’m afraid I don’t have an answer for that.

It is heavily dependent on drive speed and number of times you’d need to repeat. Each time you copy data into the RAID, the array would need to write the data plus figuring out the parity data; then, when you expand the array, the array would need to be rebuilt, which takes more time again.

My only tangentially relatable experience with something similar scale is with raid expansion for my RAID6 (so two parity here compared to one on yours) from 5x8TB using 20 out of 24TB to 8x8TB. These are shucked white label WD red equivalents, so 5k RPM 256Mb cache SATA drives. Since it was a direct expansion, I didn’t need to do multiple passes of shrinking and expanding etc., but the expansion itself I think took my server a couple of days to rebuild.

Someone else mentioned you could potentially move some data into the third drive and start with a larger initial chunk… I think that could help reduce the number of passes you’d need to do as well, may be worth considering.

Honestly I think this is a standards issue not an Apple or Google issue.

Apple needs to serve their clients and iMessages is great for that. Google needs to serve their clients and they’re putting forward their RCS extension, which could be good if they can gain traction, but their reputation precedes them, so thats going as well as anyone would expect. Neither parties really have obligations beyond, as the standard beyond their own offering is SMS MMS which they both support.

GSM is responsible for the next evolution of the carrier level messaging, which is RCS (without the E2EE extension Google is putting forth), and it’s their job to make that the standard implemented by all carriers. It’d be great if they add E2EE to the standard, but the fragmentation ant carrier level isn’t going to magically resolve if they cannot get carriers to implement it properly.

They’re going for RAID5, not 6, so with the third drive these’s no additional requirement.

Say for example if they have 2x 12T drive with 10T used each (they mentioned they’ve got 20T of data currently). They can acquire a 3rd 12T drive, create a RAID5 volume with 3x 1TB, thereby giving them 2TB of space on the RAID volume. They can then copy 2TB of data into the RAID volume, 1TB from each of the existing, verify the copy worked as intended, delete from outside, shrink FS outside on each of the drives by 1TB, add the newly available 1TB into the RAID, rebuild the array, and rinse and repeat.

At the very end, there’d be no data left outside and the RAID volume can be expanded to the full capacity available… assuming the older drives don’t fail during this high stress maneuver.

Even if you could free up only 1GB on each of the drives, you could start the process with a RAID5 of 1GB per disk, migrate two TB of data into it, free up the 2GB in the old disks, to expand the RAID and rinse and repeat. It will take a very long time, and run a lot of risk due to increased stress on the old drives, but it is certainly something that’s theoretically achievable.