The article is extremely shallow beyond saying "Formal verification a la SPARK" should have been used, while not offering how this could actually work in the real world - I don't think the author has any experience working on any similar piece of software either.
While such techniques are available, would they be really applicable in a very dynamic environment such as with millions of PCs running various windows versions, needing continuous / real-time updates.
And yes, we of course know that QA and testing magically removes all possible failure modes/bugs.
> While such techniques are available, would they be really applicable in a very dynamic environment such as with millions of PCs running various windows versions, needing continuous / real-time updates.
I don't see much difference in complexity between the affected software and the several existing formally verified software. At the very least the parser/interpreter could very much be formally verified.
But my point is, have they tried? They don't seem to be even aware of such.
The thread is still wrong, since it was a OOB memory read, not a missing null pointer check as claimed. 0x9c is likely the value that just happened to be in the OOB read.
There are actually some patterns to deal with this, such as Saga - I'm actually working on a project (not open-source yet) related to this specific problem. You can reach me at can@hazelcast.com if you want to learn more.
Sagas are definitely what OP should look into here. Quite frankly, transactions are a bit of a fools errand beyond a certain scale, yet are still treated with some absolute purity from the days of Cobb. If you have multiple changes that need to be made, the "all or nothing" approach makes it really simple to deal with and manage.
Sagas are about recognizing the individual changes that are necessary, and dealing with the success or failure of them at a higher level. This is complicated though as the developer and the business now need to have a specific conversation around what happens if A succeeds and B fails? Does A need to get "rolled back"? Does B need to be retried? Does C need to wait until B succeeds before proceeding? That all brings in a level of complexity and the only answer is to manage and use the appropriate patterns and tools to do so. Wanting to go back to a land where you can just wrap it all in a transaction so that you get one nice boolean indicating success at the end is quite frankly just naïve. The real world doesn't work like that.
Threads are similar to slideshows - you can put a few bullet points that sound reasonably correct, but lacking in detail and context and you mostly forget about it after you read it, it's disposable.
A long-form narrative that is convincing and made to last and read repeatedly is much harder to write.
Your salary is only partially based on "the value created by employee" - most of it is the market forces of supply and demand. When you're remote, you're competing with a much larger number of people for the same positions.
Salary is always lower than the (expected) value of work. If the value of work was equal to salary, the employer would have to reason to do this transaction.
The price of everything is always between the value placed on it by the buyer and the cost to the seller. Not a revelation.
At the margin, they are all equal because trade continues until the gains from trade are exhausted.
In many countries and U.S. states, laws guarantee that the cost of an employee to an employer is almost twice as much as what the employee is paid. In those circumstances, the potential gains from bilateral trade are not exhausted and people engage in that trade outside of the dominion of the state.
That's it. I believe, like in any market the top earners, who are hard to get and hurt when they go will continue to get high pay. Since even if you include the world (and most jobs don't, they include some timezones, jurisdictions only) the market is still rather small.
But if you're just the average developer, like most of us really are - the higher competition will surely make it harder to negotiate higher pay.
> In many countries and U.S. states, laws guarantee that the cost of an employee to an employer is almost twice as much as what the employee is paid.
This might be true at the lower end close to minimum wage, but payroll taxes are a specific % (usually around 15% at the federal level, and the employee pays about half that) and insurance and other benefits are typically a fixed cost per head (15k to 30k per year at most of the places I've worked). The only thing that might be variable are things like 401k match. Once you get to six figure salaries, the fully loaded cost per employee is 120-130% of their salary.
> Your salary is only partially based on "the value created by employee" - most of it is the market forces of supply and demand.
Value created is the driver for the demand side. Yes, the supply side will differ regionally, but for a service that isn't differentiated by the region it comes from, that doesn't matter—the law of one price should, in a competitive remote hiring market, prevail equalizing wages for remote work. Firms trying to normalize location based pay are trying to short-circuit the law of one price—or at least slow the development of equilibrium by introducing friction—by way of creating artificial market segmentation, which can only work so long as the market is not competitive because of either a monopsony or an explicit or tacit agreement not to compete for labor.
The public discussion that passes for transparency and explaining to prospective workers isn't just about that, it's most signalling to other employers to get them onboard.
> Firms trying to normalize location based pay are trying to short-circuit the law of one price—or at least slow the development of equilibrium by introducing friction
Considering the firms lowering the prices are currently paying far above the median in global wages, they’re doing the exact opposite of short circuiting the “law of one price”.
The whole reason for paying higher than median wage was the friction of being geographically located in high demand areas.
Do you mean for a single job/pipeline? This wouldn't be possible at the moment. Our current focus has shifted from Beam a little bit - as we found out the beam threading model didn't play nicely at all with Jet's green threads (there is no way to distinguish between blocking and non-blocking calls).
While such techniques are available, would they be really applicable in a very dynamic environment such as with millions of PCs running various windows versions, needing continuous / real-time updates.
And yes, we of course know that QA and testing magically removes all possible failure modes/bugs.