justin_oaks

First, I agree with you. Dealing in nearly all crypto-currencies is financially irresponsible whether it's your own money or other people's.

That said, perhaps Hanes would have been duped by an similar non-crypto scam. It seems that all he needed was some online contacts and a fake web page with numbers on it.

Ultimately, it wasn't the crypto that was the problem. The problem was that he stole other people's money. He didn't mismanage it; he stole it.

"Past performance is not indicative of future results"

People are unreliable. They change their behavior based on circumstance. The person who posted the pledge may well mean it right now, but then some things change and it all goes out the window.

Even worse is that companies change hands. The old owners sell or, heaven forbid, the previous owner dies. When companies change owners, all previous promises have no meaning.

Thanks for the heads-up.

I'm curious at what would be stored in the session to make it large enough to be a problem, but it's good to know to watch out for it.

I previously used openssl-based scripts to generate certificates to use for local development or applications on a private network. I have since moved to using the step CLI [1].

OpenSSL is powerful, but it's hard to figure out how to use correctly. Each command seems cryptic no matter how many times I use it.

The step CLI is a lot simpler, even though it has a few quirks: generating PKCS1 formatted private keys instead of the newer PKCS7 format, making every leaf certificate eligible to be either a server certificate or a client certificate, and absurdly low default certificate expirations.

1: https://github.com/smallstep/cli

You act like an organization is a single person. The person saying "Sorry, I can't help you" when you visit Google headquarters is not the one ruining your income.

And they can have you trespassed. Hang around after that and the cops can arrest you.

Thanks. I've used oauth2-proxy with NGINX. So I could try to set up oauth2-proxy with Caddy in a similar way.

I was checking into using Caddy for new projects instead of NGINX or Apache HTTPD, but my new projects require OAuth2/OIDC authentication. It seems there's not built-in support for that kind of thing. There's the caddy-security plugin, but people online have been saying it has disclosed security vulnerabilities that aren't being fixed.

Are you using caddy-security? Or is there a better alternative?

I was an employee of a company providing security services. I can attest to that company being filled with generalist programmers.

None were trained in security principles. None were security experts. And there was no security review.

Which makes me wonder if there is a way to simulate multiple repos while maintaining a mono repo. Or mirror a portion of a monorepo as a single repo.

Obviously this would be a real pain to implement just to fix the underlying problem, but it's an interesting (awful) solution

Yes the default certificate duration is so small as to be useless as a default. It's a pain to set the expiration in hours, but it does still allow you to set months or years of duration. You just have to calculate out how many hours those months or years are.

In every organization I've been in, "later" meant "never".

Exactly. There's no "just" when you're adding an API. APIs require a lot of work and complexity to do right:

APIs need to be well-designed or the client may need to make multiple API calls when one should suffice. Or the API could be confusing and people will call it wrong or fail to use it at all.

APIs require authentication and authorization. This means setting up OAuth2 or at least having a secure API token generation, storage, and validation.

APIs need handle data securely or you'll leak data you shouldn't, or allow modification you shouldn't.

APIs need to be performant or you database may be crushed under the load. This may involve caching which then adds the complexity of cache invalidation and other servers/processes to support caching.

APIs need to be rate-limited or sloppy clients will hammer your API.

APIs require thorough documentation or they're useless. You may even have to add SDKs (libraries for different programming languages) to make it easier for people to use the API.

APIs need good error messages or users who are getting started will not know why their calls are failing.

I figure it's because AWS can get away with it.

I hope for a day where "Caveat emptor" will no longer be needed, but today is not that day!

And that's perfectly fine. Such people will get less favorable terms.

Patrick's guide explicitly talks about how a lot of people don't want to negotiate. His argument is that if doing something distasteful for a short period of time will get you a significant salary boost, you should try to do it anyway.

Ultimately, if it's distressing to someone to be assertive and negotiate, my first reaction isnt "That's fine! Let's all work together to make things nice and easy for them!" My reaction is "It's sad that it's so distressing, but one way or another they need this important life skill. Let's help them acquire it, even if it's difficult."

That 128KB only applies to non-standard S3 storage tiers (glacier, infrequent access, one zone, etc)

S3 standard, which is likely what people would use for git storage, doesn't have that minimum file size charge.

See the asterisk sections in https://aws.amazon.com/s3/pricing/

My upgrade policy for everything:

Significant security vulnerability? Upgrade

Feature you need? Upgrade

All other reasons: Don't upgrade.

Upgrading takes effort and it is risky. The benefits must be worth the risks.

> It really feels like early 1990s vintage Unix software. It's clunky and arcane and it's hard to feel confident doing anything complex with it.

How software "feels" is subjective. Can you be more specific?

> all the great productive feedback that awesome people give over the web

Yup, sounds about like what you hear from your average keyboard warrior. I wish there were a "low effort" filter on comments.

> I'm the opposite of stubborn: a sabotaging level of flexible.

That's tough. Hang in there. Keep making cool stuff. And thanks for sharing your creations with the world.

Thanks for sharing! Just the idea of it is entertaining and makes me smile.

> Not only did nobody use it but the response was universally discouraging and negative.

What were the negative things that people said?

When I showed up, someone was writing "Cthulhu 2024!" I think we know what Cthulhu's campaign promises are.

It seems like the doctor has fallen victim to the politician's fallacy [0], summarized well on Wikipedia as

1. We must do something.

2. This is something.

3. Therefore, we must do this.

People seem to feel like there's merit in "trying something, anything" even if by trying something you may actively make the problem worse. We need to accept that we only have limited control. Bad things happen.

0. https://en.wikipedia.org/wiki/Politician%27s_syllogism

What are your credentials?

If I see a sell-by date, I only use it to compare between individual items. If there's a shelf with bread and two items have different sell-by dates, I choose the one with the later sell-by date.

So how does a diabetic get one of the older, worse insulins that they can afford? Certainly that's preferable to the better insulin that they can't afford.

I looked into Envoy a few years ago and found it difficult to get started. I recall the syntax involving long names that were hard to look up from the docs.

I'm assuming some of those issues may be why it isnt as commonly talked about as nginx or caddy

Google may use many anti-competitive practices, but that doesn't make them wrong when pointing out specific anti-competitive practices in their competitors.

I'd be quite pleased for ALL the big companies to point out their competitors' anti-competitive practices.

Edit: For context, the parent commenter was saying something similar to "The pot calling the kettle black"

I also don't like AWS's odd names, but there are competing priorities when choosing to name something. I thought of some things to consider when you're naming which may make you choose a (possibly terrible) proper noun instead of a generic term.

* Is what you're naming a product which you can trademark? Or is it just a feature that would be silly to trademark? (EC2, Sagemaker, CloudFront vs account, billing profile, user)

* Does the name help with people differentiating your product from your competitors product?

* Does the name help people find the product when searching online?

* Does the name help ensure that the product isn't regarded as "Just a (generic term)" when it is more than that?

The sad thing is that politicians who get these laws passed don't want to collect data about whether the laws were successful.

If they collect data and it turns out the laws aren't helpful or the laws are actually harmful, then the politician's career and reputation may be trashed. But if they pretend like the law can't possibly be bad and never check on that, then they're protected.