The other problem with the Concorde was terrible fuel efficiency
To be fair, Concorde's fuel efficiency was way better than what some other aircraft could do at that kind of speed.
Concorde really was a technological marvel of its time.
3275 publicly visible posts • joined 30 Jan 2010
Partial failures are the hardest to spot and defend against. So many times I see high-availability systems die because they failed in an obscure and non-obvious way.
And as we make our systems more complex & interconnected (ironically to try and make them more resilient!) they become more susceptible to catastrophic outages caused by partial failures.
I don't know about this particular course, but we've had some of the Office 365 courses run by Microsoft engineers (not trainers) and go into way more depth about the topic than is available in the standard docs. Those courses were not cheap but the staff who attended them rated them as some of the best they've every attended as the engineers knew their stuff and didn't blindly follow a PPT.
Unless your back up solution is written to understand your database application, restoring individual records in a database is usually not a trivial exercise. It's not like you're picking a couple of files from a filesystem backup. You're going to have all sorts of referential integrity pointers that you're going to have to re-setup as you re-insert the data back into the system.
In short: Databases can be big & complex beasts. You only truly value your local DBA once you f**k up and they pull you out of the hole you've dug yourself.
As a manager, if you need to block your team for an entire hour to inform yourself on progress, you're doing it wrong. There's a big chance that Sally doesn't need to know about Jack's problems, and is wasting time listening to them. You're the manager.
For the size of teams I manage (all less then 10) I disagree.
Before lockdown I'd have weekly meetings with each team and during the meeting someone would mention something and others would pick up on it and they'd discuss the topic. It was my job to tread the fine line between allowing this to happen as it was a Good Thing and stopping the discussion going waaayyyy off topic or the meeting dragging on.
Now with lockdown, I tend to be a bit more lenient on keeping team meetings focused as it's bloody good for everyone's mental health just to have a little bit of group banter.
Regardless of what that was, we’re surely not alone in this vast galaxy of billions of stars let alone the vast universe with billions of galaxies.
The chances of there being other, intelligent life, out there across the cosmos: Very high.
Chance of us encountering these other civilisations: Zero. (Untill our knowledge of the fundamental laws of physics changes to allow practical interstellar travel)
Oracle has not said if its VirtualBox desktop hypervisor will target the M1, but a port is considered very unlikely due to technical issues
I read that thread. I don't think it's "technical issues" I think it's people getting confused what hypervisors do & do not do and hence what they can expect.
You've made an assumption: That manufacturers thoroughly test their code before shipping. From bitter experience, they don't.
Some of this is down to laziness.
But for large pieces of software, testing can take weeks to run and cost six or seven figure sums. And that's just to run the tests that have been written. It could be an order of magnitude larger (or more) if tests have been written for every code path.
But a large part is that the customer's use of a vendor's products in ways more complex or creative than the manufacturer ever thought possible. And when it comes to distributed systems, testing is a harder still. (Hello race conditions!)
Summary: Testing is hard. Good testing is even harder.