The two are completely district languages. Kind of like comparing Java with JavaScript.
I'm sure in general Microsoft would love to scrap VB in Excel but there's too many companies that run entire areas of business on it, or the whole business itself.
It is the typical legacy/back compat problem. Python or even Powershell would be a vast improvement, but you're going against billions in sunk cost/skills/knowledge.
VB.Net was slowly losing popularity, VB in Excel isn't.
Would it be impossible for Excel to allow coding in multiple languages? I totally get that there's a huge (disturbing) amount of business critical stuff using the current scripts, but they really should move on to something more modern.
Multiple-language runtimes typically don’t get popular - people just end up choosing one language and standardizing on it. See for example Windtows Scripting Host: you could always use Javascript with it, but almost nobody ever did in practice. After a while, typically the vendor sees other languages as a drag on development, and they get dropped in favour of the main one.
Retrofitting a multiple-language runtime under VBA would likely be a big endeavour, and in the end most people would probably stick to the established language anyway.
Microsoft pretty much built it (would allow any .net language to behave like VBA, with an integrated IDE and ability to save code inside the document). Then they killed it. I think that was a huge mistake from a productivity point of view, and also to get a fighting chance to retire VB6.
> Better to isolate services from each other limiting cross service jumping, than to build security around a single point of failure
I agree that it is better, but let’s not forget that building security around a single point of failure is still an improvement, that is simultaneously both high and low friction.
Bad: everything exposed to the internet
Good: everything behind a VPN
Best: Every application on its own micro-segment with access control up to the application layer to restrict all forms of access beyond the bare minimum of what is required.
Perfect is the enemy of good.
> Google has gone the opposite direction
Google scale solutions are great for google scale organisations. They don’t always scale down very well.
> Every application on its own micro-segment with access control up to the application layer to restrict all forms of access beyond the bare minimum of what is required.
I hope for the operator team that they have good tool support to help administer all the access controls. Over time and across large organisations there are going to be a lot.
The even larger challenge must be auditing all these access controls. Services change, and if a connection is not required anymore, it should be painless for its operators to get rid of the corresponding access control.
We added an iPad and tried to purchase something, but the only card on file was long since expired and thrown away.
But in order to verify the account we had to enter the card's digits, which we did not have, and we couldn't add a new card because we hadn't verified the old one.
In other words we were stuck. Had to contact Apple support. Took several days to resolve.
Same here. Apple's process for dealing with lost or stolen cards is just insanely stupid. Why in the world do I need to 'validate' the existing card, which I no longer have, in order to add a new one?
What possible security or business justification could exist for that? What does it even mean to 'validate' a card you've been billing successfully for years?
(Spoiler: in case this happens to anyone else, the secret turns out to be disabling family sharing on the account. It will then let you remove the old card and add a new one, after which you can re-enable family sharing.)
No way...I don't remember hearing about this. You mean changing the URL from like /data/customer/1 to /data/customer/2 ? And the person who did this was prosecuted? Jeez.
AMP is built on Google's CDN, and the standard is controlled by Google for Google's own self interests.
It being "open source" or not kind of misses the bigger picture. If Google had any interest in AMP being a web standard they would have sent the spec out, and helped fund a neutral org to run it.
And then a second crash occurred where they followed Boeing's procedure, it didn't work, were forced to diverge and then crashed.
Boeing's procedure only works if you catch it quickly. If you let MCAS trim the aircraft too much it is difficult to recover, particularly at low altitude.
Mechanical keyboards require deeper compression and are thus the opposite of what you want. They'll worsen strain.
Have you checked your chair/table height, monitor height, and are you placing both feet on the floor? You might be able to mitigate this without buying things.
That's commentary. We can reasonably speculate they were looking at warnings and the flight log, autopilot is only one part of the flight director and as autopilot was never turned back on, pointing at it seems odd.
Changing settings in the flight director is very much an action (not mere commentary). Plus it's a good distraction from flying the plane — especially while the overspeed alarm is going off.
Overspeed is the result of the mistrim. They were in fact flying the plane, the significant back pressure they used to fight the mistrim makes that clear. On what basis do they anticipate 4 seconds after two successful nose up trim using yoke toggle switches (manually initiated, electric motor turns jackscrew) that MCAS will cause a 40 degree nose down within seconds?
Nothing. There's no basis for expecting such madness. The emergency AD following LNI610 doesn't at all account for significant mistrim, the possibility of heavy jackscrew loading forces that could prevent manual (handcrank) retrim, and the necessity of setting stab trim switches back to normal to solve the mistrim.
It's realy vile to me that this whole mistrim scenario was not thoroughly explored by the FAA and NTSB (independently of each other) in 737 MAX capable simulators following Lion Air 610. Very clearly the emergency AD was still inadequate months after Lion Air 610. Could ET302 have been prevented? Perhaps, but not based on the then published AD.
No, it wasn't. Overspeed was because the pilots basically firewalled the throttles and never once touched them. Look at the Lion Air flights, they never came close to those sorts of speeds.
If I'm trimmed for level flight and go to 100% power, I will not overspeed. Initial airspeed increases, the plane starts to climb, airspeed decreases, and fairly quickly without any other inputs the airspeed will return to level flight airspeed, but I'll be in a climb. It's basic aerodynmics. Primary flight students are taught this, and in more advanced training it's given a name: positive static stability. All FAR 23 and FAR 25 certified airplanes have this behavior.
In the case of ET302, the power settings were completely normal for the phase of flight they were in. What was abnormal was the trim. If the trim were normal, they would have had a normal climb and normal climb speed. On what basis would or should the pilots have made a power reduction?
In the case of LNI034 and LNI610, you're determining speed how? Do you have a page reference? Are you even able to estimate percent Vno? What I see for LNI610 is normal takeoff power, and just before midway through the flight a power reduction. Airspeed isn't affected. And how are you comparing the stabilizer trim setting value between LNI610 and ET302?
In the case of ET302, the power settings were completely normal for the phase of flight they were in.
N1 was nearly at 100% for most of the flight. ET302 had an unreliable airspeed situation, yeah? My understanding is that the memory items for this on the 737 involves setting the throttles to well less than 100% (closer to 80-85% is what I've seen). Honestly I thought climb thrust was around 80% as well.
On what basis would or should the pilots have made a power reduction?
Both the overspeed clackers were going off for much of the flight (granted so was one of the stick shakers — at the same time).
In the case of LNI034 and LNI610, you're determining speed how?
The initial leak of the preliminary report included units with the graphs.
Another example of Dunning Kruger effect here. I assume you're competent at something, that's as polite as I can be. But the way you willfully ignore my power and trim explanations and yet continue to armchair pilot by mischaracterizing the importance of the power setting, while also implying the pilots were incompetent, is shameful. But you are so incredibly ignorant, you have no idea, so you persist in being obtuse. That is how a real pilot and flight instructor will view your characterizations. And even as I try to school you, you ignore it. Your defect is significant enough I do not have the time or interest in schooling you anymore.
FAA emergency airworthyiness directive 2018-23-51 directly contradicts much of what you are saying and implying.
The PDF you cite, if authentic, and if the units are the same between LNI610 and ET302, indicate substantially more nose down trim for ET302. And that is consistent with the airspeed differences, not power.
Since you seem eager to accept more rope and hang yourself with it: ET302 05:41:15, take the airplane state at that time, and only do a power reduction, explain what you think will happen and why, in sequence with and emphasis on the force changes that happen including change in attitude.
Maybe, just maybe, when you're in a plane that does not respond to your commands, you want to have a look at the most likely possibility: the autopilot did not disengage, or the autopilot malfunctionned and prevents you to get full control of the airplane. IF hte pilots knew about MCAS, they would likely have checked that instead, but they did not.
Most pilots are rationnal and pretty smart people. Implying that two of them are stupid enough to "play" with the autopilot in this situation is pretty insulting.
This kind of reactions are interesting though. I might tour facebook, twitter and reddit to see if it's widespread.
If the client hashes the password then the hash itself is the password. Meaning stealing the hashes passwords is the same as stealing the plain text password for which they're based, since you can post them direct.
Blizzard entertainment does half client half server hashing which is rather clever, one of the few examples where client hashing makes sense.
I'm curious, how is half-hashing the password different from really hashing it?
The best protocol I know of is to derive a signing keypair from your (salted, stretched) password, and store the public key on the server instead of a password hash. Then during login, the server sends a challenge to the client, and the client signs it. The server never sees any secret material at all. Keybase uses a version of this protocol.
Unfortunately all the magical client side crypto in the world doesn't save you if the attacker can compromise your server and then send clients bad JS :p
I'm sure in general Microsoft would love to scrap VB in Excel but there's too many companies that run entire areas of business on it, or the whole business itself.
It is the typical legacy/back compat problem. Python or even Powershell would be a vast improvement, but you're going against billions in sunk cost/skills/knowledge.
VB.Net was slowly losing popularity, VB in Excel isn't.