chiisana

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.

Apple is implementing it because China requires all 5G phones to support RCS to get certified.

Apple did not do this because they suddenly have a change of heart about the green bubbles. Apple did not do this to spite regulatory bodies and ‘malice compliance’ with some interoperability mandate.

This is not a move to make messaging more secure with the green bubbles. This is not a move to make messaging better with the green bubbles. This is a move so they can continue to sell phones in China.

Yeah I know what you mean. Grandma’s the same… she doesn’t care if it doesn’t look good when zoomed in, she just wants to see the picture.

Sorry to be the one to break it to you… if that’s the feeling you’re getting, then they most likely don’t care enough…

Very much as expected… fragmented, incomplete, and highly dependent on carrier. Google’s non standard E2EE extension will likely only work if messages are routed through their servers, which based on the observations here, even from the Android side it doesn’t seems to be routed through Google. Larger file means better quality pictures via green bubbles, anyone who’s sent/received a garbage and cares enough knows to send via third party messaging apps anyway, so nothing life changing here.

Let’s see if Apple applies pressure and push everyone to use Google’s servers for E2EE as they move towards iOS 18, but other than that… I’m still inclined to think the down play during keynote is apt.

Need the phone to sync, the watch can keep track of health data until it gets back close to the watch. If you have the cellular version, and an applicable data plan, you can make and receive calls with it without your phone, too.

Strictly speaking, they also have wifi, but power management on them (due to the limited battery) makes it pretty difficult to actually use effectively.

Pretty sure UniFi Access can also control the lock mechanism they’re describing. So it’d be a nicely integrated solution.

You aren’t wrong, but that’s also the point… It makes no difference if they’re securing a VPS or their own network. In fact, they’d need to secure both systems — and I’ve seen so many neglected VPS’s in my time… I’ll be the first to admit: myself included.

There are very valid reasons to need a tunnel; CGNAT, ISP level port blocking, network policies (ie campus dorm), etc etc etc. However, if you read the other replies, this doesn’t seem to be the case here, and OP doesn’t seem to even know why they’re hiding their IP. They just wanted to do it because of some loose notion that it may be nice since they’re opening up their port.

For someone in that situation, introducing a whole stack that punches through the firewall via an VPN or alike introduces way more risk than just securing down the gateway directly, and handle the other issues as they come up.