Look at the hoops you sometimes have to jump through or hacks you have to apply to make something work on Nix, just because there is no standardization or build processes assume library locations etc. And if you then raise an issue with the software maintainer - the response is often "but we don't support Nix". And if they're not Nix/Nixos users, can you blame them?

If you've ever had to compile a modern/recent software package for an old distro (I've had to do this for old RH distro's on servers which due to regulations could not be upgraded) - you're in a world of pain. And both distro and software maintainers will say "not my problem, we don't support this" - and I fully understand their stance on that, because it is far from straight forward, and only serves a limited audience.

Well there's salary, and total employee cost. Now sure how it works in Sweden, but here in Belgium it's a good rule of thumb that an employer pays +- 2,5 times what an employee nets at the end after taxes etc. So say you get a net wage of €3300/month or about €40k/year ends up costing the employer about €100k.

I'm a freelance devops/sre/platform engineer, and all I can tell you is that even for long-term projects, my yearly invoice is considerably higher than that.

Sorry but if you allow your platform to sell 3rd party content, you better have some consumer protections built-in in your contract with that 3rd party in case of such a scenario.

On top of that, people still building an i3-design printer from scratch is rare, the hobbyist design community has moved on to the Vorons, which means pretty much all printers with this design are from companies with zero community interaction, profiting from the Prusa investments. So I get why they're not happy.

The only real comparison you have with Prusa is the much less popular RatRig - which is still an opensource design afaik, but I'm not aware of any clones of those.

Just publishing the specs will not allow anyone to send/receive iMessages. It's built on a closed loop CA / certificate system.

Remember that Steve Jobs actually announced on-stage it would be an open protocol without actually discussing that with his engineers? The architecture is designed to be closed from the get-go, and opening up the iMessage ecosystem in it's current design is simply not possible without giving 3rd parties considerable access to Apple internals, affecting a ton of stuff beyond iMessage, and pose serious security risks.

Could Apple re-design a messaging system which would allow this and roll it out transparently to all it's users? Absolutely, but that would require a ton of engineering work, and won't be there tomorrow.

Since they involved CIQ, I'm pretty sure they are now paying support for Rocky, which, if you read the article, was clear they didn't mind paying for. It was the per-cpu subscription that was not realistic in their business model.

Sorry but that is something he should know. That directly affects technology radar and roadmap, HR and a bunch of other stuff.

And the people here shouting matrix and "don't go to discord" have never tried to push more non-technical people onto it. It starts with differently named apps on desktop and mobile (sure there are a few multi-platform clients). But then the naming? Back in the old days, IRC for a lot of people was not IRC, but mIRC. Why? Because the icon they had to click had that name. Thank goodness it at least resembled the name of the actual thing they were connecting to, where they could go "IRC? you mean mIRC?".

If I now tell someone to go on matrix - they don't have a matrix app on their phone, Mac or pc, and I have no idea which-one it'll be. Branding and name recognition is important here.

And Texas has a lot of sun during moments with peak usage (aircos) - so it you'd have to be an absolute moron not to see the advantages there, but for example in Germany they're going backwards here, they use coal and gas to replace nuclear - in a time where our primary focus should be on producing as little CO2 as possible - which is just another level of stupidity.

Kubernetes is not just "a tool", it's a platform. So if you know the k8s fundamentals, being dropped in an unfamiliar environment should not be a problem. It's the same as knowing your way around a Linux system, you might not be familiar with that specific distribution you're thrown into, but you should be able to explore the system and figure stuff out.

> Also, what is a k8s engineer? What's the difference between this engineer and a "devops" engineer? This and software engineer?

Any engineer who claims to know a bit more than the basics of k8s? It being a software, "devops", SRE, "platform", ... engineer doesn't really matter, I've been labeled all of the above.

I'll never claim k8s is perfect, I have plenty of issues with it, but very few of them are an architectural problem, and I've yet to encounter a platform that attempts to address all the issues k8s does. But you seem to be very critical of it, so what would you propose as a viable alternative?