189 karma · joined February 22, 2011
Apparently EU vaccines are produced in Europe, maybe there's something wrong in the local production facilities that's causing this. UK has only used AZ vaccines produced in the UK, afaik.
You could take inspiration from plantuml-editor (https://plantuml-editor.kkeisuke.com/#) and add a template/demo button that allows user to get a predefined diagram so they can experiment with it.
If I were to guess, they use the picture as a connectivity/speed test. They probably figured Wikipedia has unlimited free bandwidth, so they didn't care.
But based on FATCA, only the other countries have a responsibility of reporting wealth information about US citizens, while if you are a Russian or a Brit or whatever you can safely stash all your wealth in the US if the tax regime is more lenient than your own country.
Just a small correction, you've got your data the other way around. Early to mid April when Asparagus-Gate happened, Romania had at the very worst 500 new daily cases for a population of 19 million, while Germany regularly had 4-5000 for a population of 83 million.
So in essence Germany was a hotbed.
Forcing them to use public standards and forbid them to develop their own? You can't possibly believe that, you're literally stifling innovation. A much better approach would be to force them to make their standards public.
It's my go-to tool whenever I need to document something visually, whenever I have a meeting with my peers and I want to get them quickly up to speed with the process I have in mind, I just create a quick sequence diagram and we can hit the ground running.
[0] https://plantuml.com/state-diagram [1] https://www.planttext.com/
What this means is that the packets are encrypted between you and the video bridge and the packets travel unencrypted within the videobridge infrastructure, but at no point does the outside world see the unencrypted stream. Talking to the Jitsi video bridge is just a regular WebRTC session as far as clients are concerned (so any DTLS encryption WebRTC has, the Jitsi call has), I know this because before they had a decent SDK I had to manually wedge my WebRTC calls into it.
If you're looking to add e2ee to your project, you're pretty much left to choose between Olm and Signal Protocol, which are quite similar, but libsignal is GPLv3 while libolm is Apache 2.0.
I've used Olm more intensively over the last two years. While it works, it's great, when it randomly wedges a session for no apparent reason you feel like throwing it out the window.
You're not sending unencrypted streams to Jitsi, as it uses hop-by-hop encryption, meaning you send an encrypted stream to the server where it gets decrypted and re-encrypted for the rest of the participants. At no point you are sending "plaintext" data. What you might have heard is that Jitsi will be introducing end-to-end encryption, but it doesn't mean it doesn't have encryption at the moment.[1]
I think it's a misnomer to say WebRTC end to end encrypted by default.
If you cannot guarantee end to end encryption during the negotiation phase, you cannot trust that the party you're encrypting for/receiving encrypted content from is the actual party you are expecting to communicate with, hence the need to independently verify over a trusted channel whether the fingerprint in the SDP offer/answer matches.
After the negotiation is complete, the streams will indeed be encrypted, but if the offer/answer SDP has been tampered with by the signaling server, which is under the control of a rogue/compelled provider, and another DTLS certificate has been inserted, the encryption is useless as far as complete communication security is concerned.
Xcode is dreadful with its strange fetish for recompilation even if there were no changes and the compiler is slower with every iteration. The solution put forward for this always seems to be "buy newer hardware".
By this point's it's obvious to everyone that the engineering of the plane is pretty far down the line of causes which lead to this.
There was a Twitter thread[1] a few weeks ago which explained it very clearly:
Some people are calling the 737MAX tragedies a #software failure. Here's my response: It's not a software problem. It was an
* Economic problem that the 737 engines used too much fuel, so they decided to install more efficient engines with bigger fans and make the 737MAX.
This led to an
* Airframe problem. They wanted to use the 737 airframe for economic reasons, but needed more ground clearance with bigger engines.The 737 design can't be practically modified to have taller main landing gear. The solution was to mount them higher & more forward.
This led to an
* Aerodynamic problem. The airframe with the engines mounted differently did not have adequately stable handling at high AoA to be certifiable. Boeing decided to create the MCAS system to electronically correct for the aircraft's handling deficiencies. During the course of developing the MCAS, there was a
* Systems engineering problem. Boeing wanted the simplest possible fix that fit their existing systems architecture, so that it required minimal engineering rework, and minimal new training for pilots and maintenance crews.
The easiest way to do this was to add some features to the existing Elevator Feel Shift system. Like the #EFS system, the #MCAS relies on non-redundant sensors to decide how much trim to add. Unlike the EFS system, MCAS can make huge nose down trim changes.
On both ill-fated flights, there was a:
* Sensor problem. The AoA vane on the 737MAX appears to not be very reliable and gave wildly wrong readings. On #LionAir, this was compounded by a
* Maintenance practices problem. The previous crew had experienced the same problem and didn't record the problem in the maintenance logbook. This was compounded by a:
* Pilot training problem. On LionAir, pilots were never even told about the MCAS, and by the time of the Ethiopian flight, there was an emergency AD issued, but no one had done sim training on this failure. This was compounded by an:
* Economic problem. Boeing sells an option package that includes an extra AoA vane, and an AoA disagree light, which lets pilots know that this problem was happening. Both 737MAXes that crashed were delivered without this option. No 737MAX with this option has ever crashed.
All of this was compounded by a:
* Pilot expertise problem. If the pilots had correctly and quickly identified the problem and run the stab trim runaway checklist, they would not have crashed.
Nowhere in here is there a software problem. The computers & software performed their jobs according to spec without error. The specification was just shitty. Now the quickest way for Boeing to solve this mess is to call up the software guys to come up with another band-aid.
I'm a software engineer, and we're sometimes called on to fix the deficiencies of mechanical or aero or electrical engineering, because the metal has already been cut or the molds have already been made or the chip has already been fabed, and so that problem can't be solved.
But the software can always be pushed to the update server or reflashed. When the software band-aid comes off in a 500mph wind, it's tempting to just blame the band-aid.
[1] https://threadreaderapp.com/thread/1106934362531155974.html
Only to be placed in a $10 case with bunny ears so it won't crack if you accidentally drop it.
The alternative is to paint the contents of the cell manually (that is without using UILabels and the such) using CoreGraphics.
Check out the drawContentView: method here: https://github.com/ferostar/fast-scrolling/blob/master/Class...