Re: CC
That's a great solution if you're at a level where you only need to send an email to one person at a time, but it's going to make day to day collaboration difficult
771 publicly visible posts • joined 12 Jun 2013
Yes, really. The CLOUD act applies to governance rather than ownership. The fact that it has US owners is irrelevant as long as the US owners don't have seats on the board (which, as far as I can tell, they don't).
Also, if we're unhappy with that, what's £3bn to the government in exchange for sovereignty?
If my only choice is guess, rely on AI, or say I don't know then I probably would lean towards the AI answer (obviously depending on the consequences of the answer). It doesn't look like the participants were allowed to verify the answer elsewhere though. This isn't really any different to people using Wikipedia as a source, just the tool is different.
I've seen this in the UK. Hospitals are quite bad for mobile reception for various reasons, and the police aren't allowed to connect their equipment to unsecured WiFi networks. Their choice is to go outside or use a personal device. When you're there supervising someone going outside is not always a practical option.
> First, the iPad that wasn’t turned over clearly was not locked to the point where someone else couldn’t get into it
iPads tend not to support user accounts, so the usual process is a shared pin code but then requiring individual sign in to whatever apps you're making use of. If it's a shared account too then the pin code is probably considered secure enough.
> I wouldn't say BitTorrent is inefficient
Depends on your use case and the perspective you're looking at it from. For distributing large files that never change it has a good user experience. For optimising backbone network bandwidth you can't beat a CDN: your traffic stays within your network instead of crossing peerings and continents.
> What Borkzilla should have done is simply alert all existing users that there is a new platform they can migrate to while keeping their existing environment and that they should do it because the existing platform is getting old and becoming obsolete.
You mean by giving you 4 years warning like they did a couple of years ago, and 2 years warning today?
And changing instance types is a scriptable operation (until you get to v6) so you can do it in a scheduled maintenance window.
What would be nice if they had an option (like container instances) for "I don't care which CPU I run on". Then they could take care of it for us.
> What this incident brings into focus is the fact that there is a trade-off. By moving more interactions with our bank online, we place our faith in technology which can suffer unpredictable errors.
Unless their staff are using a disconnected paper system, this has very little to do with customers interacting with the bank in an online manner. A race condition could still happen on staff terminals.
I'm not saying prices shouldn't change, I'm saying the losses aren't "realised" until you sell the bond, which is reinforced by the SVB scenario: They didn't have enough funds to cover withdrawals which led to them having to sell at a loss. Even then, it wasn't selling them at a loss that was the problem (I imagine this happens all the time, otherwise bonds would never decrease in value), it was their shady accounting and the ensuing panic.
If you are planning on holding the bonds to maturity, the day to day value is irrelevant. It only becomes relevant if you want to sell.
> Interest rate/bond rating define their present day value
Not quite, it's the price of the last transaction. If I wanted to offload a significant tranche of bonds then I would be very unlikely to get that price for them, the price would decrease as the supply increased.
I had developer support for an API platform tell me to clear out my cache and cookies the other day.
If they'd have bothered to look at the attached network request they'd have seen that no cookies were sent and it was their API choking on some data.
I felt like asking them to forward on the request to someone who could spell API...