cpitman

Sounds like you want to configure a Group Mapper: https://www.keycloak.org/docs/latest/server_admin/#_ldap_map...

I very much agree, it's a big assumption that burnout is only cause by too much work or too much pressure. When that assumption is unchallenged, it can lead to managers dismissing concerns about burnout because their teams are not overworked.

A lack of meaning to the work, or even a lack of work overall, can also cause feelings of burnout. A lack of obvious career progression can cause burnout. Constantly fire fighting can cause burnout.

So if someone says they are burned out, I always ask what is causing it before talking about solutions.

I wonder how much it actually is. I push back hard on anyone trying to bring in a distributed database that has not had a report released by Jepsen, but I wish there was the funding and/or capacity to release updated reports more often.

Great post. This one always brings a smile to my face:

> Every component is crash-only

I was part of the team that developed a distributed, five-9's control system for an industry where downtime costs millions per minute and comes with a federal investigation if long enough. On top of that, the industry is made up of competitors that explicitly distrust each other, so all components had to be truly distributed, with no central coordination for anything.

Given the requirements we decided to explicitly adopt a crash-only approach. Between idempotent operations, horizontal scaling, and fast restart times, we could make failing components not impact SLAs (and we had testing to ensure it).

Once it gets out into the field (which because of how risk adverse this industry is, is measured in years), it turns out they really did not like software crashing. They interpreted crashing as bad quality, and no amount of "we do it on purpose to ensure correctness" was going to make them happy.

I work for Red Hat, we do it all the time. We often acquire closed source companies and then release the software as open-source, while continuing to offer it.

I believe the most recent example was Stackrox, open sourced March 31st. The "productized" version is Red Hat Advanced Cluster Security. https://www.stackrox.io/blog/open-source-stackrox-is-now-ava...

I agree, better to open source a product then to just let it die off. I just wish companies were honest in their headline ("this product didn't work out, here's the source") instead of trying to spin it.

I wish people wouldn't use "we open sourced it" as a synonym for "this product is dead". Especially for a SaaS company, there is a totally valid business strategy in open sourcing your codebase but continuing to provide a paid SaaS offering for users that are not interested in self-hosting.

It causes confusion every time a company open sources their software. Always have to wonder, "Is it dead and they are yeeting it over the fence?"

At many of my clients, when an app breaks on kubernetes, it's generally on the admins to show that it wasn't the cluster's fault before the app team tales ownership of the issue. Tools that help very clearly show that traffic made it to the app, and what the app responded with, are super helpful.

I work for a company, Red Hat, who's entire business model is getting companies to provide ongoing monetary support for our engineers to work on open source software. We spend a lot of our time advocating for open source, we started well before open source was broadly accepted, and this kind of action could be a setback.

100%. I've already seen articles in non-tech media that explain what happened to a non-technical audience, and the explanation sounded a lot like open source is the problem and that proprietary software would never have these problems.

It wasn't that long ago that using open source software required a lot of politicking inside my clients, and we could easily go back there with enough spooked executives.

The author is a contributor to Apache ShardingSphere. https://github.com/apache/shardingsphere

It doesn't sound like they did. They asked about family background, which often is a way to say "tell me about where you come from?"

The telling part is the kids assuming the most important part of their background is religion, region, and caste.

Literally going through this right now. Performing the upgrade from 13 to 14, following the required upgrade path.

In the past, you could go from current version -> latest z release -> X.0 release of the next major -> latest minor release of Z. As long as gitlab completed the db migrations and came up, you were (relatively) ok to continue to the next upgrade.

Turns out 14 introduces a brand new upgrade failure case. Starting with 14, upgrades can include async db migrations that must complete before you continue upgrading. But once you start upgrading, it's too late, things are hosed, so now I'm falling back to a backup and starting over.

Does anyone use k8s clusters that don't come with Ingress these days? This article exposes a lot of complexity for what should just be "use ingress".

More advanced ways to get traffic into the cluster are only really needed for non-https traffic. It comes up, but way more rarely.

This is very common for my clients. Another common variant are B2B focused clients where their customers contractually require them not to put data onto AWS. IE, Walmart doesn't want any of their data to end up on AWS, and if you want to do business with Walmart you need to similarly protect their data.

This is an open source project from the start (as most things red hat creates), you can find the coffee here: https://github.com/redhat-et/microshift

I had another version of this at the DMV. They needed to see bills that offered proof of my residence (ie power/water/etc). Turns out they wanted them to be mailed to you, which wasn't going to work because I do paperless billing for everything. So I printed them out and tri-folded them as if it had been in an envelope.

People in front of me in line got turned away for using printed bills, but mine worked just fine.

They were often doing full blood draws, not finger pricks.

For anyone who wants to see this data without running the numbers themselves, the CDC has a dashboard showing total weekly deaths per week over the last several years, the trend line, and the obvious significant increases over the last couple years. They update it weekly, but it takes a couple weeks for the data to become accurate (the recent weeks have always been an undercount while reporting catches up).

For interpretation, the orange line is average expected deaths for that week, and you'd expect weekly deaths to cluster around that. Red is the "upper bound threshold", ie deaths over this are way out of the norm.

You can also switch the dashboard to "Excess deaths with and without COVID-19", which shows the same bar chart but with reported covid deaths stacked on top of non-covid reported deaths. It makes it clear that (1) excess deaths line up very well with reported deaths and (2) the US has done an overall good job of reporting covid deaths, outside of some probable undercounting at the very start.

https://www.cdc.gov/nchs/nvss/vsrr/covid19/excess_deaths.htm

There are updates from this month at the bottom!

In my experience, mainly in the non-tech enterprise space, the classic sysadmin team is allergic to writing code that would require ongoing maintenance. The most they would do is write a throwaway script, or possibly have their own personal set of scripts. But write an actual tool for broader consumption? Never.

It's one of the biggest differences I see day to day in enterprise operations and developer mindsets. Developers generally do not worry about who will support code before they write it, because their entire job is to write code. Operations teams on the other hand want to find an off the shelf tool, with enterprise support, even for what could be a fairly simple task.

This implies that the issue is due to being open source. The majority of closed source software, especially in house software, has minimal or nonexistent documentation. If there is any, it was likely done once at the start of the project and never updated since.

I've been a consultant for over 10 years. I always make sure to ask for access to any documentation for systems I'll be working on. I think I've gotten significant (out of date) documentation maybe once. This isn't an issue stemming from being open source.

No, that graph may be hard to understand. It shows the relative improvement each GC has made since Java 8, not the absolute performance.

Or people select those degrees for non-monetary reasons. I highly doubt anyone is getting a degree in religion for the earning potential. Similarly, there might be other non-monetary benefits, like social capital, for going into fields like art.

The average student loan debt for a US undergraduate degree is ~$37k, which lines up with that $9k/year.

When people talk about tons of student loan debt, they are invariably including graduate students getting professional degrees, like law and medicine. The average student loan debt after medical school is ~266k. But compared to the earning potential of a doctor (starting salaries between $200k and $500k), that isn't some unrecoverable debt load. The only people really screwed are the ones who decide they don't want to be a doctor a couple years in.

https://educationdata.org/average-student-loan-debt#by-educa...

I took a stab at a basic Floyd-Steinberg dither, but at the low resolution and with even really subtle video camera noise, the result was not great.

Until I took my glasses off... with just a bit of blur, the effect is pretty cool. Probably doesn't make sense to push a feature though that only works when you squint at it!

For what it's worth, the analogue to Anthos is AWS Outpost.

But you could argue Outpost still has a more clear name for what it is, although I wonder if they actually thought through the definition of the word: a small military camp or position at some distance from the main force, used especially as a guard against surprise attack.

That's not accurate. There was an older project called podman-machine, which is long gone. What you get when you use the `podman machine` command is a completely new implementation.

There's a great little video log following someone doing exactly this, acquiring an akiya house and renovating it (https://www.youtube.com/channel/UCBQ3TEq5SrUuTJuMl1S_4ig).

He starts from how they bought a house, to the state it was in when they started (spoilers, no one had ever emptied the fridge when the last occupant died), to the work done by a local carpenter and the work he did himself.

I think the second one is a massive issue. In an in-person world, mentoring and role-modeling happen all the time. Junior employees see what their seniors are doing, even when the seniors do not plan on being seen.

In the remote work world, junior employees can only see their seniors at defined events. Lots of mentoring needs to move to explicit mentoring relationships, and people have to move from "showing the right behaviors" to "explaining the right behaviors". And that assumes the mentee/mentor even know what behaviors they need to focus on! In person, you just get to see everything.