Time to audit all their contributions although it looks like they mostly contribute to xz. I guess we'll have to wait for comments from the rest of the team or if the whole org needs to be considered comprimised.
stsquad
joined 2 years ago
NI is just another tax that goes into the total pot, albeit one that is not progressive and adds to the cost of employment. I'd be happy with it being scrapped and it all going on income tax, perhaps with a scaled employer contribution component. How about the employer contributes a scaled percentage for all employees over the median income for the company?
Microsoft has been working with a number of open source projects for some time now. It shouldn't be that surprising anymore.
European systems have quite a bit of private provision but they are still generally single payer and heavily regulated. Private involvement in healthcare doesn't automatically involve what they created in the USA.
I think narrowing it down to one tax type isn't overly helpful. Ultimately it comes down to spending and policy. We underspend and we are more reactive: https://data.oecd.org/healthres/health-spending.htm
Systems that are insurance based (ignoring the mess that is the usa) at least have an incentive to catch things early because they are cheaper to deal with before they become chronic. With delays in primary care and waiting lists we end up getting much less bang for our buck as conditions develop before getting treatment.
We have a lower tax burden than most of Europe, or at least the ones with decent healthcare. https://data.oecd.org/tax/tax-revenue.htm
I have not, but I will now thanks.
The declarative approach also allows for better composability - user tweaks can just be the relevant lines on top of the packaged default config.
You can end up with a lot of boiler plate code and with duplication you run the risk that one unit tweaks the boiler plate in a way that behaves differently. This isn't insurmountable and a lot of rc scripts source a library of common functions shared between units. However from the point of view of the executor each unit is it's own whole ball of shell script code.
Yes training is the most expensive but it's still an additional trillion or so floating point operations per generated token of output. That's not nothing computationally.
While shell based RC systems do offer flexibility they also have downsides including copy and paste leading to subtly different behaviour across units. Dependency resolution was also a bit of a hack on top of scripts to deal with concepts like run levels.
The declarative approach of a proper configuration is a better and more scalable solution.
It's looking more like a long game to compromise an upstream.