koffiezet

No Belgium either, which I would have expected since tax rates here...

It however shifts a lot of the complexity of building the application to the distro maintainer, or a software maintainer has to prioritize for which distribution they choose to build and maintain a package, because supporting them all is a nightmare and an ever shifting moving target. And it's not just a distribution problem, it's even a distribution version/release problem.

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.

When interviewers use LLM gargbage to filter out participants, expect candidates to do the same.

> Just curious. In Sweden the average devops salary is around 60k.

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.

I used vagrant in the past for this, but that's years ago.

This is something I was actually looking for a while ago and settled for a linuxserver's docker image running vnc and sqlitebrowser to inspect some databases on my homelab, which felt like an unsatisfying solution - this looks a like a much nicer, better and more lightweight solution.

Not if they require a certificate containing the serial number/imei/... + a nonce provided by Apple, signed with a private key/certificate stored in the secured enclave, loaded into the device when it's manufactured.

> Somehow I think this one is not Sony's fault entirely.

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.

Sure, but the communication channel between the attester and the client which it needs to verify/attest is pretty much undefined?

What unclear to me is how the actual verification by this attester would happen. Somehow the attester, which is also a remote service, verifies your device? Are there any details on how that would happen specifically?

I think their main problem is that regarding the i3 design, they are pretty much the only-ones contributing to improvements, I mean - when was the last time the community (or another manufacturer) actually contributed anything useful to the core HW and electronics design? The 3d printing space has massively changed in the last 10 years, where initially a lot of the HW improvements came from the hobbyist RepRap community. Now they come from a single company which stems from that community, and which is spending money on R&D.

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.

> beyond allowing others to send/receive messages

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.

> They were using CentOS for no cost previously and have switched to another no cost RHEL rebuild (Rocky).

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.

> doesn't know that his core infra team just wrote something in Rust

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

While it might suck for some people, the 10k message limit was always there, so if you wanted to keep history - why the hell would you be on slack?

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.

While I think not allowing windows is a silly policy, Apple laptops still sell for a serious premium after 3 or 4 years of use. I've worked for companies where this was the sole reason for Mac being the default laptop you got. If you wanted/needed anything else, you had to specifically ask for it.

It's never an "or" thing, it's an "and" thing, we need both. The more renewable we have, the better, but for a base-load it's hard to have this everywhere and batteries are far from an ideal solution. We don't need nuclear to replace wind/solar, we need it to replace the oil/coal/gas which we can't seem to get rid of for that base-load.

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.

Let's be clear here, everything you can do in a "cloudy" environment, you could do on big servers yourself - but at what engineering and human resource cost? Because that's something many - if not most - hardware and 'on-prem' infra focussed people seem to miss. While cloud might seem expensive, most of the times, humans will be even more expensive (unless you're in very niche markets like HPC)

Well, sadly they are not

> So your point is that once you learn how to use the tool it's easier to use the tool?

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?

Not for windows native images (which are a thing, but does anyone actually use them?) So in theory, no you don't need WSL.

Can you elaborate on what mainframes do better? I'm genuinely curious (not being too familiar with mainframes).

Microvms are just the workloads, while Kubernetes is a platform, mostly agnostic of that workload. Yes that's currently mostly containers, but you can already schedule VMs on k8s with KubeVirt.

What k8s offers is a platform, on which people can build their own solutions. It makes solving a lot of very hard problems a lot easier and portable. Before k8s, tools like these were out of reach for small/mid companies with only a handful of dev-teams, but enough for organisational scaling to become a problem. K8s allows self-servicing while still enforcing standardisation.

And I'll give you another use-case I'd like to see you replicate with any other existing platform: migrating an entire on-prem application stack of 200+ services to the cloud. It took us 3 weeks total to do for a client of mine, where the hardest part was the migrating state with minimal downtime, and a lot of work went into the IAC part for the GKE setup.

Also, institutions like banks have now jumped on the k8s (well, mostly openshift, but same thing) train, I'm pretty sure it's here to stay.

Any decent k8s engineer worth his salt should find it pretty easy to navigate this, since how you deal with that is pretty standardised.

I've written custom operators and submitted upstream patches to existing-ones, it's not that hard once you know what you're dealing with conceptually.

That's why I'm interested in what wireguard op these devices would do, there's a library for that, but haven't experimented with it yet.

My initial impressions back in 2013 when I started using Go was that it's development environment was annoyingly opinionated (the GOPROJECT env var crap, which is now gone). I was mainly using C/C++ at the time and for smaller tools python. Go with it's static binaries however looked like a very interesting python alternative, so I tried it anyway, and found a language that was very easy to dive into. Took me only a few days to really feel comfortable with it, which surprised me a bit.

My main take-aways, other than what is mentioned in the article:

* it was a lot easier and even a natural thing to dive into other people's and even the stdlib's code. I had been coding in C/C++ and the only time I did that was when I was tracking bugs. Now I just do it to figure out how things are done or even out of curiosity.

* libraries are source-code only. This is great for developers, and is a large reason for the previous point, but some businesses are hesitant towards this. One thing to always keep in mind here however is licensing.

* while not actively encouraged, the way you write Go pushes you towards writing reusable libraries, with just a small wrapper frontend. You see this in many larger projects you can easily integrate many in your own application.

* the standard library is fantastic, and contains a lot more than many expect, but clearly shows what the target audience is: operations and backend development.

* dependency management used to be garbage, this has massively improved. Not perfect, but better.

* Cross-compiling is a breeze. Coming from C/C++, this blew me away. Even when using CGo, which complicates things a bit, there is pretty good tooling around this.

* It's very opinionated, but most of the times, in my opinion, right.

It ended up replacing pretty much all my need for C/C++ code, except for embedded Arduino-like hobby stuff, and I haven't looked back. The main valid thing I've seen people complain about is the lack of a decent multi-platform GUI library, which I don't need, and is always a mess anyway. Web-frontends are a thing though, and goes hand in hand with Go being pretty damn good at backends and APIs.

Where's the time where you could just assume it was DNS.

I think one key aspect is lost here. A thing automation does is compartmentalise, abstract and remove the need for in-depth understanding by/for everyone involved.

It's the reason why container images are the latest form of packaging for certain types of applications: it streamlines the interfaces towards applications even more. Configuration is usually done with environment variables, or even abstracted further with something like helm charts to deploy on an even more abstracted platform like Kubernetes.

Things like configuration, temporary and persistent/temporary storage, health checks, services/ports, ... are all presented with a unified interface.

There's a reason the US has a symbolic military presence in Taiwan, most likely even on the Pratas island to train Taiwan defence troops there. It would be the first and obvious strategic target, and taking the otherwise uninhabited island without hitting the potentially present US military personnel would be hard - which should make China at least think twice about making a move against it.