Posts by Richard 12 6093 publicly visible posts • joined 16 Jun 2009
Yes, I believe so.
However those were unmodified and flown under special rules to minimise the chance of taking out other flights or people on the ground.
This is the first flight of what Boeing are praying will be certifiable.
Of course, given that airlines worldwide are almost dead, they're far too late and may not sell any, even if it does get certified.
When you buy a consumer product or service above £100 using your credit card, the credit card company are jointly and severally liable for the proper delivery, fitness for purpose and reliability.
If the store won't pay out for a TV that broke down 'unreasonably" quickly, the credit card company must refund you out of their own pocket.
Even if the store and manufacturer both ceased to exist a year or two prior.
Consumer protection for right-pondians is orders of magnitude better.
Flights are no different, except that airlines that refuse to refund also cease to be airlines.
It doesn't appear that they have ever demonstrated all three parachutes firing yet.
Two parachutes doesn't behave the same as three. Will they actually open properly if all three deploy?
I've definitely seen more than one video showing parachutes getting entangled or otherwise failing to open because of being in a cluster.
macOS has a technical limitation that the GUI can only be manipulated and painted by a single thread.
Trying to touch the GUI from any other thread will crash immediately.
There's a lot of things that fall into that GUI bucket which you wouldn't expect (font metrics).
So you are actually forced to make a lot of things single-threaded.
PS: Don't set thread affinity. That Windows API actually makes things slower. There's another, more useful API for hinting to the scheduler about multi-socket and shared cache if you've proven it makes it faster.
Serialisation relies on exact alignment.
This will certainly expose a whole host of crashes, data corruption and security failures as the assumptions that are true for x86 and amd64 turn out to be false on Apple ARM
In many ways it's far worse than 32/64, because pointers are rarely serialised.
Exchange ain't free, and neither is a corporate Google Mail.
There's definitely a lot of people willing to pay for stuff over-and-above the core email feature set.
In many ways Hey is an email filter service, and there are several other companies making money doing that.
Virtualization also goes bye bye.
VMs do not convert the underlying CPU architecture, they are still running the VM guest's code natively.
The VM hypervisor is merely enforcing barriers between to ensure the guests don't touch each other's memory, and provides virtual IO (disk/network etc)
Emulation is needed to run amd64 on ARM (or vice-versa), and emulation has comparatively abysmal performance.
Hancock was talking bollocks. Apple say they haven't even been contacted, and it turns out that NHSX haven't even done any testing of the Apple/Google system at all.
As many people have pointed out, the technique itself has quite large unavoidable errors.
Being charitable, someone probably told Hancock that the technique is quite imprecise, and he simply doesn't understand that the NHSX app is using the same technique.
Would be very hard to explain that to him though as he has no understanding of what "2m" or "social distancing" looks like anyway.
Metal boxes are pretty good at blocking radio waves, even when car-shaped and with holes to see out of.
Aside from that, it doesn't need to be very good to be very effective, if testing is fast and provided to all contacts with appropriate delays.(something like ~5 days after possible exposure.)
Don't feel too bad though, nobody in Government has even a passing link to reality, let alone a reasonable understanding of the physical world.
The only difference is that Apple and Google know far more about the real-world behaviour of bluetooth chipsets, because they've spent over a decade working with them and contributing to the standards.
So GA's avoidable errors are going to be far smaller.
The unavoidable errors are exactly the same.
And aside from that:
It doesn't matter
2m is not a magical bubble. It's a distance where the overall probability of transmission is estimated to have dropped below some arbitrary (unpublished) level.
Halve it, and that risk is ten times greater. Presumably doubling it reduces the risk to a tenth.
So, it doesn't matter if a small percentage of "contacts" are erroneously missed or included in a 2m sphere, as long as the majority of contacts are actually included.
What does need to be done is rapid testing. Yet Hancock won't even release data about test turnaround times.
Hence the only really believable figures are "Excess Deaths".
Practically everywhere is undercounting Covid19 deaths, often with huge discrepancies.
The only exceptions seem to be Belgium and Germany, which are most likely counting some not-covid as being covid while missing some covid. So ending up with roughly the right totals, while still making errors individually.
Actually, his team probably can. I suspect anyone who has ever created an iOS/Android app could do it in a couple of weeks.
The only hard bit is defining when a given instance should broadcast its contacts list, as it'd be rather open to abuse to let users hit the panic button without any confirmation of a diagnosis.
Though on the other hand, it's not actually any worse than than asking people with a positive test to fill out an online form listing their contacts. And that is the current UK methodology.
So maybe a simple Big Red Button actually is ok.
No possible bluetooth stack could ever tell you the precise distance between phones under all common circumstances.
The stack only knows signal strength. It does not know time-of-flight.
Signal strength depends on both the distance squared and the environment.
The Apple/Google one is backed by a team with access to far better kit and with infinitely greater understanding of the physics, hardware and software in use, because they designed it.
The Google/Apple SDK is very likely several orders of magnitude more accurate and precise than the NHSX trial app, simply because of the engineering knowledge and experience that they each have.
And yes, it's not going to distinguish between "both phones in pocket at short range" and "phones in free air further apart" (if the cameras are covered), any more than you can distinguish 1G of thrust from 1G of gravity (without windows).
Physics doesn't care about your political claims, any more than biology does.
Why is it not km/l?
Honest question. It seems very weird.
My wild guess would be to make sure the numbers are wildly different so you can't confuse them, which also has the problem that the numbers are wildly different so you can't understand the "other one".
Unlike say metres and yards, which are similar enough that for many human-scale purposes it doesn't matter.
The difference is that the CPU knows it just returned, so can immediately check whether the jumped-to instruction is one of the "ok" targets.
An application wanting to do the same has to add code to function prologues to mark as "entered function properly" and also add "did we enter this function properly?" checks at various places.
Can probably get most of it by adding checks to the prologue and epilogue to trap if the function was entered without leaving the previous one, or left without entering it, but of course this is several times more code.
Not really, the main cost is a little bit of space in an instruction cache line.
The fetch was happening anyway. Is basically "jump to X", then X performs an "am I a valid jump target?" trap. With hardware support the cost of that can be zero time (but does cost transistors!) Though on CPUs without support there's a decode & NOP.
Will add more state to context switches, as this will obviously need to be explicitly enabled by processes, but context switch is already expensive.
What's the date on it?
I only ask because every public space in the entire world that has a zoned PA system capable of playing muzak does that.
Which is every cruise liner and theme park, most museums, railway stations, airports...
Heck, chances are reasonably good that Sonos' own office block has one.
Disneyworld and Disneyland have been doing this using "microprocessors" since the 80s, if not earlier.
I assume the synchronisation is the "invention".
However, "shall synchronize" is not an invention. Patents are about "how", not "what".
I am absolutely certain that there are several ways to do this.
And if either of them are claiming "synchronize clocks then distribute timestamps for points in the audio stream", then the patent must be invalidated because that is "bloody obvious to anyone vaguely aware of the art", let alone skilled.
Also SMPTE have published several standards for doing that since before Google was founded.
Not what the OP meant.
If NASA buy from a company that employs lots of US taxpayers, some proportion of what they pay the private company is paid to those workers in wages, and is taxed by the US either as wages or in sales and other consumer taxes.
In theory some part of what they pay should also become taxed profits, but that doesn't happen in reality.
So there is some valid "discounting" to be made. Not really sure how large that would be, though unlikely to be greater than 10%
Crew Dragon is definitely not selling below cost.
That would bankrupt them. They don't have much in the way of cash reserves and the contract is for a lot of launches, so they can't raise their man-launch prices for several years.
You can only do loss-leader in two situations:
It helps you sell some high-margin consumable or related products (see printers, pod coffee, supermarket) or you have sufficient cash reserves to wait out the failure of your competitors (see Amazon)
Neither of those apply here.
Except it's now back, done manually.
It never really helped for message content. It was always about attachments.
MS are now encouraging people to send attachments via OneDrive instead. So now we get single-instance storage, at the cost of forcing the sender and recipient to manually deal with it.
Such is progress.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
