If I have one feature request, it's a dedicated music (or any kind of event, really) scene thing that lets local people curate events and share them in a central town square, and lets randos find those local events. It could drive a whole lot of people who're not plugged into a scene to find awesome local events without having to go through some other portal, like newspaper event calendars, zines, rando facebook groups, etc. I spent a ridiculous amount of time curating events for punk shows by trawling MySpace pages because there was no other way to do it.

Dream bigger: why is Kubernetes so complex? Re-inventing what we already have. Why is it so complex? Lack of standards, lack of flexibility, too much focus on features.

A Linux system has a lot of complexity, but it very rarely gets in the way of the other bits, and it can [mostly] all be replaced as needed. Why? ABI compatibility, kernel-userland split, a big collection of independent composeable tools, a framework that provides everything you need but doesn't force you to use it in the most difficult way, and definitely doesn't force "patterns" on you (like "deployment").

On top of Linux, we've built the world's most advanced and wide-ranging systems, particularly because it's not opinionated. It gives you just enough rope and bamboo to build a hovel or a skyscraper. It is not modern, it isn't the best design, it doesn't force you into the minutia of understanding the system.

A new Kubernetes should either be stupidly simple, or incorporate itself into the OS, since the OS already has most if not all of the components of Kubernetes. They're just not being used properly.

I might give a shit about the mission, in as much as you can give a shit about the trite verbiage assigned to, in essense, the general thing that's supposed to increase shareholder dividends. But the mission is very frequently lost in the minutia of doing one's job. Does the mission relate to how I'm going to fill out this change management form? No; the change management process isn't based on the mission, it's based on its own thing. I give a shit about the change management process. If I only gave a shit about the mission, I might say, "screw change management!" And then I wouldn't be very good at my job.

And "giving a shit" based on who's interpretation? I can tell you that I give far too much of a shit about how my company works, and if I voiced this frequently, people would be absolutely sick of me. My manager sometimes reminds me - in the nicest terms - to calm the fuck down about the work. You don't want the whole company filled with people like me, because they'd drive each other bonkers. A few of us are nice for variety, and to pop up occasionally and say, "Hey, do we have a central place we can put all this documentation rather than a lot of independent places?" And then calm the fuck down and focus on just writing the damn docs.

You should want people to care, in a healthy way, both about the thing they're working on and the way in which they work on it. But you should never want them to be obsessed.

Obsession, n: Compulsive preoccupation with a fixed idea or an unwanted feeling or emotion, often accompanied by symptoms of anxiety.

If you want this for your employees, you need to get a grip and re-evaluate life.

If you've gone hungry before, you remember how painful it is. But most of us don't, because we literally have so much food we throw it away. But that's definitely not everyone's reality.

All you actually need is a stripped-down REST API (or some wireline protocol with 4 fields) and a TLS connection. No need to require DNS or DNSSEC at all.

The registrar generates a unique token for whatever the domain owner wants to manage a cert for that's based on their domain. "oj3942hur9h239rh9hr4394834r domain.com" or "92839ub9f93hh9hsjdksjd * .foo.domain.com", doesn't matter. CA makes a request with the token and the CSR, registrar looks at the CSR, finds the record matching the token, finds that the CSR matches the record, signs its reply "yes, this is valid" with its own key, and the CA obliges the user. You don't even need DNS to make the request if it's hosted on some static IPs.

If anyone's seriously waiting on DANE in order to resolve a handful of security vulnerabilities that affect the entire Internet (because at this point the entire Internet's security hinges on TLS), we might as well also wait for Jesus to come down from his bachelor pad in the sky and solve our national debt.

The easiest way to vet them is to call them and ask them what their policies are, then test them (for legal reasons, against your own test domains would be best...). See whether you can find documentation about their policies online. If you can't find them: potential red flag. If you can find them but it doesn't seem thorough/very secure: red flag. If they don't seem to deal with international customers: potential red flag. If they don't support TOTP or U2F, or you can't disable SMS validation: red flag. If their password policies suck: red flag (just create a free account and see what it lets you use). If they don't do both registry & registry lock for your TLD, or won't explain how the process works for that TLD: run away.

Often they may document their online process for doing things like registry lock. Call them up and say you are a potential customer and you want to know what you can do over the phone, then ask them what you need to provide in order to do each thing. They're not going to try to hide anything from you, so they may tell you if (for example) all they need to know is your full name, e-mail address, and what domain you want to unlock. They'll also tell you if they only send EPP codes over e-mail or their web interface, or if they have a way to record customer support requests (like a special verification code for phone support, select lists of people who can administrate the account, etc).

Of course, it's up to each customer service rep to actually follow the Registrar's rules. It just takes one lazy SOB to skip all the steps and just do whatever you ask to ruin everything. So you might also ask to talk to whomever manages the support reps and find out more about them, like how much training they receive and how much oversight is done over each support call. You'll probably have to settle for correspondence over a ticketing system.

Registries you'll probably have to e-mail for their rules, or ask a Registrar. Some registries can be unnecessarily cloak-and-dagger about their policies, but some registrars don't care and will tell you anyway. Personally, I would stay away from the Registries that require two weeks of paperwork just to change WHOIS information.

They're pissed because they think something is wrong and they want it fixed. But they don't know what is wrong, and they don't know how to fix it. So I think they are pissed because it just seems like they should be.

> It could perfectly be due to rational reasons.

If you ask a very loud shouty person why they are so angry, they usually launch into a tirade of "everything that's wrong with the country." But you don't hear one single specific issue or well-thought-out rationale. The only common thread is cultural or political. Us-versus them; it's all those people's fault that everything is wrong. There are common themes, but no one specific root cause, issue, or analysis.

So they don't really know what's wrong or what the cause of it is. The only thing they're sure of is that something is wrong, and they grasp at whatever has been pissing them off lately. As social primates, when we are generally pissed off and think something is wrong, the most common group that we blame is "the authority" (the next-most-common group to blame being "the foreigner")

The general evidence I give is here (https://news.gallup.com/poll/1600/congress-public.aspx). In the 1970s, around 50% of Americans disapproved of how Congress did it's job. For the past 10 years, around 80% of Americans have disapproved of how Congress did its job.

Congress is an elected body. If the people really thought Congress was the cause of their anger, they could just vote them all out; doesn't take a genius to figure that out. Yet most people stay in Congress. So I think the anger at Congress is really just a symptom of the malaise, regardless of whether Congress does either a good or bad job.

All you have to do then is wait for things to upset the public, like a mandatory inconvenience, for them to start to protest and later revolt. It's similar for both Black Lives Matter as for no-maskers/no-lockdowners. They're pissed that the system is corrupt and imposing itself on them. At that point they may throw out any institution of authority if they feel oppressed by it.

But there's a couple big problems that these points raise:

1. Why don't engineers design for production, and how do you get them to? I find most devs just do not want to care about how their apps actually work. They don't care about the product or user experience. Getting them to care is hard.

2. Deployment is not a problem - an ongoing site reliability process is the problem. Anyone can ship some code to a server accessible on the internet. But what do you do when it breaks? Or even worse - what do you do when it's just getting incrementally slower? Deployment is just one tiny part of getting your code to production in such a way that it continues to be a functioning product. Site Reliability is really Product Reliability - and that's something devs need to learn about.

3. The company never wants to pay for anything, yet they insist on hiring people to build stuff by arbitrary deadlines that can't be met. How can we fix this? Beats me.

4. A person manually checking for quality is basically a relic of old managers who have no idea how to get quality other than to pay someone to care about quality, but they don't know how to get those people to do the right thing, which is work with devs to write tests.

5. Simple things are the hardest to make, and definitely takes the longest to get right. I would start with easy, and try to work my way up to simple. Simplicity being complexity reduced to its most essential parts. I think all refactors should be always towards simplicity, and should happen often.

6. The reason that building or running systems can be so difficult or error-prone is human communication problems. Look for communication problems and solve them, and you will magically see less errors, more frequent deploys, and happier customers. Yes, this is kind of obvious, but it's amazing how often communication problems are both known and ignored because "we're too busy because we've got to do X other thing".

The latter is the best option as it's much more scalable and doesn't require ugly proprietary hacks. Docker in Docker requires vertical scaling and more complex management for intermediate states/maintenance.

Podman probably isn't ready to replace Docker yet, but rootless containers are the easy-mode for federation of clusters. If you can supply the other features you need (and I think most can) it's probably worth it in the long run.

Philosophy is doing a bad job of explaining its importance to the world. Philosophy nerds care about it, but everyone else thinks it's stupid.

Says a guy talking about being part of a music subculture. Does nobody get the irony?

  - they want DNS over TLS [multiple reasons why].
  - they want to work around "problems" in the architecture of DNS.
  - they want to force new functionality [read: protocol changes] on users without other DNS infrastructure adopting it.
  - they can.

If you love privacy more than freedom, DoH is great. If you want the internet (and local/private networks) not to resemble America Online, DoH should frighten you.

Is it because Starbucks has the most efficient cost outlay for long term investment in a user's needs?

Or is it because people just want some damn coffee and there's one on every corner?

Or is it because, in a world full of places to buy coffee, one place gives you everything you could ever dream of in a coffee place?

That is what the big cloud providers are. They are Starbucks. They are not the cheapest. They aren't even the best. But they are everything you want.

If your company gets Starbucks-huge, you don't need to buy your coffee from Starbucks. You have your own deals with roasters and your own supply chains and baristas and coffee logistics experts.

That's why some companies build their own. Not because it's a better idea (it's not), or because Starbucks costs too much (compared to the investment in re-creating Starbucks?). It's because they are a business that effectively makes their own coffee already, so it makes no sense to pay Starbucks for it. Of course, they won't have a Starbucks once they make their own coffee, but they will have served their needs well enough.