CorvusCrypto

That doesn't make it better imo, though someone commented under my other response to this that in reality it wouldn't be so noticeable which is good. The moment it makes a noticeable and lingering change in the sky picture, however, I would hope people accept that it would be time to reduce the clutter

Hmm no. That does put me at more ease.

And yeah I included that last part in the estimate for seeing up to 50, otherwise the projection would be of course up to half of all of them.

That's good then. And no I don't think it's uglier. You're right that many of the billboards and such are ugly but I still believe this to be ugly as well and I don't thing something being uglier invalidates it

Someone else commented something that puts me at more ease but it is worrying at first glance.

Hmmm well I hope it's not noticeable because starlink is planning 24 orbital planes with 60 satellites per. With that it's safe to say you could see up to 50 or so of them in a night due to the constellation pattern. That's a lot of flickering and moving light in the sky when coupled with AWS' initiative also. I'm hoping your right but at first glance it doesn't seem great.

Okay that's interesting but I have to say it's also quite ugly. Is this a new trend to cluster satellites like this? If so what advantage does it bring and is it worth that ugly streak appearing in the night?

I get this comment is very subjective but surely I'm not the only one thinking it's a bit of an eyesore

Yes that she was an agent at the time. But no that she had access to those materials. There are various levels of government access. Even if documents are marked "secret" and you have secret clearance if you don't have the passwords you don't have access. And actually in government sometimes you do have the passwords and still don't have granted access. Any tampering with a computer to gain access you didn't have approval for from your supervisors is considered hacking. Yes it's an internal IT violation, but at a government office which makes it a government offense. I hope that makes sense. It's not like a normal company where you get repercussion from that entity alone at these sorts of government orgs.

At face value it doesn't seem so crazy to charge him for this. I mean it is committing a crime by proxy as opposed to passively obtaining information from a source (the latter of which journalists should be protected for).

If I give tools and a robbery checklist to someone and tell them to rob a bank, surely I'm still able to be charged and probably for a higher crime right? At least that's how these charges seem to me. I guess I don't see how it's invalid.

I do however see how this could set a dangerous precedent should the courts allow loose interpretation of the outcome to mean "reporting leaked information is illegal"

I was definitely one who thought it should be so simple to follow a standard stab trim runaway and made several comments to it too. But the more it drags on the more I'm learning from the data that the procedure to correct is just bullshit.

Boeing is now in unsaveable waters for this situation and all doubt is being removed. I still am upset that any airline was able to in good faith say "nah we don't want all the safety options not worth it" but here it doesn't seem it would have helped much the more data comes out.

The rule is clearly stated in the swedish article that during these drives a person must be present with one hand on the controls just I'm case. Same saftey net, really, remote or not imo makes no difference

My whole take on this:

Commands can go through message busses and be managed easily or it could just be a sequence of async requests, but regardless of what drives commands and events at that point you should have a very solid CQRS architecture in mind. What should be acknowledged to the client is that the command was published and that's it. The problem is of course eventual consistency but it's a trade-off for being able to handle a huge amount of load by scaling separately both COMMAND handlers which perform data modification, and EVENT handlers that allow the side effects that must occur.

In a typical web app setup I would define a request ID at time of client request. The request creates a COMMAND which carries with it a request ID as well as a command ID. This results in an action and then the EVENT is published with the request ID, command ID, and event ID.

To monitor you collect the data and then look at the timestamp differences to monitor lag and dropped messages. With the events, you get all the data necessary to audit what request, and subsequent command, created a system change. To audit the full data change however, and not just which request caused what change, you need to have a very well-structured event model designed for what you want to audit.

You can't guarantee when a command or subsequent event will be processed, but that's fine. That's the whole point around eventual consistency. It's a bit uncomfortable at first, but use the lag monitoring and traceability as a debug tool when needed and really it's no problem. Also just shift the client over to reading from your read-specific projections on refresh or periodically and data will eventually appear for the user. It's the reason sometimes a new order might not appear right away on your order history for instance on Amazon, and in reality it's fine 99% of the time. Never have your client wait on a result. Instead think: how can I design my application to not need to block on anything? It's doable though it is quite hard and if you've only designed synchronous systems it will feel so uncomfortable.

And remember some things should not have CQRS design, backed by a message bus or not. These will be bottlenecks but they might be necessary. The whole system you design doesn't have to stick to a single paradigm. Need transaction IDs to be strictly consistent for a checkout flow to be secure and safe? Use good old synchronous methods to do it.

Core in all of this is data design. If you design your entities, commands, or events poorly, you will suffer the consequences. You will often hear the word "idempotency" a lot in CQRS design. It's because idempotent commands are super important in preventing unintended side effects. Same with idempotent events, if possible. If you get duplicate events from a message bus, idempotency will save your arse if it's a critical part of the system. If it's something mild like an extra "addToCart" command or something, no big deal really, but imagine a duplicated "payOrder" command ;).

To summarize, I correlate output to commands and requests by ensuring there are no unknown side-effects, critical synchronous components remain synchronous, designing architecture that compliments the data (not the other way around), and ensuring that the client is designed in such a way that eventual consistency doesn't matter from the user perspective when it comes into play.

Okay. Calm down for 1. Also the prelim data is there to review. The graph shows clearly there's a large plunge and there absolutely was a negative g report in the prelim showing that at the final few moments the trim settings from the FCC gave another correction. As for the cutoff, the report annotations tell you when they toggled the cutout switch. I went back and yeah actually you're right it was only once to cutoff and back to normal sorry for that mistake. However the overspeed is still supported from the data and yes the data shows vertical g forces and at the end there was a lurch of -2 Gs before total loss. It's on page 27.

As for less speed causing more nose down moment, yeah but at the same time they weren't in a descent for that portion either, nor were they nose down (this from page 26). The data shows they were oscillating though climbing slightly while they were overspeeding. In this case it could have helped to reduce the forces at play. I think it was more that they were just busy and left thrust settings where they were from takeoff.

I get it. I understand everyone's frustration. In similar fashion I understand how unlikely it is a crew would have the mental capacity to deal with stick shakers, GPWS callouts, and still fix the problem and that is the tragedy here. However the report said they followed proper procedure but look at the data. 95% N1, turning auto trim on and off a few times, the last time causing the huge -2G bump. There also is not enough data to us yet to determine they did regain control of the plane before enabling electric trim again. I don't think in the case of runaway trim you are supposed to keep switching the cutoff and leave your plane above Vmo. Something doesn't add up according to the data imo.

Yes I agree. And I'm pleading that everyone also recognise the other aspects of these.incidents such as improper basic procedure. It's all of the above.

Edit: And remember at the end of the day, these airlines and pilots agreed to fly the plane. Even in the wake of the LionAir incident. At the end of the day, the pilots choose to fly and can say no if they aren't comfortable. And if the answer to this is that there is pressure from airlines to keep flying? We just found another major issue and danger in aviation

Edit2: should clarify actually that I agree it's a bad design. Not about the procedures being "unintuitive". If the pilots think the corrective procedures are unintuitive they shouldn't fly any 737 since stab trim systems exist on all 737s and require the same corrective procedure in runaway stab trim.

Yeah I clarified in the reply that I don't think it's one or the other but all of the above. I'm trying to supplement the author's write-up, not override it. I hat that it's become a case of a single fault. It's not. It usually never is. And people are arguing only one side or the other. In every incident we need to look at the whole picture.

It doesn't refuse to disable. People are mixing this up with overriding control inputs. It is still possible to take MCAS out if the control loop using stab trim cutout. However when left active it does override pilot inputs. Think of it as the alpha authority that exists on airbuses. However if you follow proper stab trim runaway procedures you cutout stab trim taking MCAS out which restores pilot authority. Again this procedure should be second nature to 737 pilots of any submodel.

In your example, if there were adaptive cruise control, I would turn off cruise control by hitting the button. Same options are present here. However it does mean that braking or acceleration would be overriden until that happens. But the real analogy is if all drivers had to be trained that you turn off cruise control in runaway. If you don't do that, well then you will crash and it's from system failure AND improper general procedure

I think it's not just that question and this is what I dislike about the whole discussion. It's all about Boeing and no one is also asking "if proper procedure was performed for runaway stab trim (again, a generalized memory item) would the plane have crashed? And it does seem the sentiment is to hell with anyone suggesting pilots and airlines involved share part of the blame despite evidence.

I could also ask, would the plane have crashed if it WASNT a max and another stab trim system failed?

It's both. We need to look at everything otherwise we will end up solving only 1 part of the issue.

Edit: To address something you mentioned about root cause (in aviation it's almost never a single root cause and I will give an example that shows such cases here). Let's look at another situation: Assume P&W designs an engine model a plane uses. The plane they are used in has in-air engine fire procedures that must be performed in order to mitigate disaster regardless of the engine model used. Now imagine the new engine design causes more engine fires. If pilots don't manage the problem appropriately when it occurs, what is the root cause? The poor engine design? Improper training from the pilot? In my opinion it's, again, both. Poor training coupled with higher chance of system issues.

This article seems to focus on things from a perspective of things from a small plane pilot. So a little wider perspective might be helpful.

A 737 first off is not a Cessna like the author mentions flying. You do not get to use direct inputs easily nor do you want to have to fight stab trim because the force on the stabilizer control surfaces is muuuch higher than those on a slower flying plane. Because of this, when the 737 came out there were designs for trim systems that can help. These systems work by adjusting the trim settings for pitch using motors (like the author mentioned). However sometimes these systems would give erroneous inputs to the trim. The system might be causing incorrect trim up or down depending on the failure. This is officially known as stabilizer trim runaway. The procedure for this has been well established as a memory item meaning all pilots of 737s must be able to correct this without referencing a checklist since it is so dangerous. And it is HARD to correct because of the aerodynamic forces on the stabilizer. You can find videos of training for it. Now they introduced MCAS. A system designed to adjust trim automatically to compensate for the shift in the moments acting on the plane due to powerplant placement, etc. This adjusts the trim as well to prevent to high of angle of attack that would allow these different moments to introduce a stall situation. So what procedure should you use if it starts giving incorrect inputs? That's right, the stab trim runaway procedures, which again should be a memory item all pilots of these 737s should know and be ready and able to execute. The differences between systems that cause it just means you are taking different systems out of the control loop. This is also why I believe the FAA said it was fine to forego full airframe certification requirements. The procedures for handling the plane just didn't change drastically enough.

Yes there was negligence on Boeing's part, but I also think it's worrying that the reports seemed to indicate that the correct procedures for runaway stab trim were not followed which could have saved lives (e.g. turning MCAS back on while dealing with runaway stab trim). Also something to note is the plane in Ethiopian airways' crash was flying with "unusually high thrust settings". Remember the aerodynamic forces that make runaway stab trim a bitch to deal with? Well those forces get stronger with more speed. People are quick to point the finger at Boeing and surely they ARE at fault in some ways, but what's worrying to me is that there are pilots that are being trained that cannot perform the proper procedures that have been known since way before MCAS. Whats more is that the motors for trim from MCAS is limited to move at a rate of 2.5 degrees over 10 seconds with a pause of 5 seconds before the next adjustment. This is definitely slow enough to give pilots time to catch the runaway trim, cutout the stab trim and regain control. Anyway I am just surprised that the engineer, working for Boeing, couldn't be arsed to also give this info which allows an alternative perspective. It is bad that stab trim runaway is happening more with this system and Boeing acknowledged it and pushed patches. It is worse imo that pilots are forgetting or just not being trained on how to recognize and correct for stab trim.

Edit: Any details or numbers about the systems I got wrong please post a comment so I can correct it.

Idk, you could go with the gripen, But tbh even Sweden thinks it's a joke. Ask anyone about it and you'll hear a lot of jokes about how they are great at attacking the ground (crashing). The same types of "why the F35 and not gripen" points came up when Norway got them. The answer is a combination of NATO + the fact that, especially compared to the gripen, the F35 is the better choice. Multipurpose, easily deployed in multiple arms of military, can hold payloads for any mission type, etc. Sure it would be quite poetic to have Denmark pay Sweden for swedish planes but I don't see it happening soon.

I would say Stockholm is a tech hub in Scandinavia. There I worked 45-50 hours per week.

In comparison to LA where I recently moved back: I work 40 hours a week, barring any emergency that may come up. Though LA isn't really a tech hub so maybe it's not a fair comparison.

In both places expectations are unwritten, so to speak, as laws prevent abuse of labor. However in either case you are pretty well compensated for overtime.

what? no they don't.. This is completely dependent on where you live. In stockholm, absolutely the roads are kept clear first in many areas, as well as the rails with plow trains. Then they have plows for the sidewalks. In Ursvik it was certainly the case that they kept the roads clear first

Not to mention many kommun areas' snow are managed by its citizens (t.ex. the areas southwest of Farsta Strand). It's not uncommon that areas don't get plowed at all and people just chance driving it.

Blatant exaggeration of limited cases where this is true imo.

Hmm I often wonder why California doesn't implement a congestion tax. In Stockholm you need to pay around 4$ if you want to drive on the highway during certain hours into and out of the city.

I can't say if it works to reduce congestion but it does even the field and it certainly made me want to not drive there.

Actually in Sweden you have this also. Most people just have it removed from the contract. In the US it is the same. or you get a version that instead just says they own anything done during company time or using employer resources.

I think it depends on the company too. For tech companies especially in Stockholm and Malmö, It's really easy to hire developers. If it's a startup good luck getting unpaid leave during huge rushes as well as during industrisemester. So of course as always it depends.

However the thing I think that is more unique to Sweden and drives these kind of nice benefits is that it's really hard to get rid of an employee. Employees are protected so much with rules and regulations that even if you get let go you have a required three month grace period unless otherwise negotiated with the employee.

It's not uncommon I would say to see tech workers "fired" but then still on the payroll for an extra 2 months while they are arbetsbefriad (paid leave)

Pretty nice if you know how to game the system

Then just wait till next year when CCPA comes into effect.

Why would it be common sense? Literally nothing is written about design details. At a certain point burden will fall on the user and no it's not common sense where that point lies. Legal arguments such as this case are what concretely define expectations. I get the data protection part and it's easy to just say "anyone that does X is against data protection", but implementing stuff to satisfy GDPR is a mess of grey areas. It's just as likely a company sets defaults to streamline the UI experience for a user as is the case they did it to maliciously trick users (Yeah yeah google is evil etc. Etc. But remember these decisions affect all companies). This is not to mention the fact that many companies dont even offer customized settings and simply have only blanket opt-in checkboxes.

Perhaps. Though with GDPR the framework is intentionally vague on a lot of things. You often hear about limits and design requirements and such, well those don't exist. They are just legal "best guesses" with the frameworks inherent goal as a guide. Nobody knows whether default configs are disallowed as long as opt-in is positive action. The current best guesses for that vary and all that's known in GDPR in that regard is that there must be positive user opt-in with a good faith effort of informing the user. In this sense google likely thought they were satisfying this requirement.

It can be argued and should because the arguments laid out in this discussion set precedence that acts as a more concrete requirement that sits on top of GDPR. Basically imo this could be a very interesting set of arguments that mean changes to a huge amount of websites.

What's not allowed is pre-checked opt-in. As France mentioned that's not the case for google. Only a default configuration is pre-checked. The opt-in is a separate immediately seen checkbox saying you agree to data usage for personalization etc. Along with a link explaining how to adjust.

Edit: I should say that this approach was deemed acceptable by Swedens dataskyddsmyndighet which is the government regulatory agency and is a common approach in many sites.

This is an interesting case. So France is essentially arguing that not only should opt-in be visible (as they mention it is on Google's create account page), but that configuration should be immediately visible as well. This will screw over much more than google should it be upheld.

It's interesting that this wasn't brought up to my employer in sweden. We had default data collection settings checked and in a separate view accessible by a similar "more options" toggle and it was deemed okay as long as we had a visible blanket opt-in checkbox and a link explaining the settings, how we use data, and how to adjust. Our regulators said it would be enough as the goal of GDPR is to make every use of data reasonably known, adjustable, and revokation with good faith toward the user. Yet here it seems France is arguing that it is about immediate showing of all settings to the user and that every website should tell in the user's face about every single configuration of data usage. It's possibly a good approach, idk, I feel it is a bit too annoying of a precedent and that they are nitpicking a bit.

I can't wait for this to fully play out. Regarding documentation and informing the user, I disagree with their findings entirely about the frustration of finding data usage info as all of Frances concerns were lost on me upon visiting https://safety.google/privacy/data/. To me it seems that google has made a good faith effort at least in documentation.

I don't see that as a major problem. In fact most life-changing decisions are already based on probability. Insurance companies already do risk analysis and whether the algorithm uses ML or basic statistics, there is a threshold level of confidence used.

I'd also argue it's how our brains work. Many times as we come to a decision we are going off of confidence, not true correctness. I'm the case of declaring suspicious person's, well by definition they are suspects based on confidence, not by truth. Even in court we determine verdicts based on human probabilistic confidence that comes from the evidence.

In my experience these "leetcode" interviews are just one part of several interviews. They still look toward people interactions in other interviews with managers, etc. So it's not prioritization over interaction, it's a filter for those that can't really program so they can then continue to interview and learn their personal skills as a team member. I.e. why waste a manager's time with a poor candidate.

If it wasn't the coding question interviews that warranted complaint it would be the personality interviews. I've seen plenty of people dropped because while they were smart, they were shit at working with other people. So yeah, hiring is a series of filters. That's life imo.