Is anyone aware of something like this for MariaDB?
Something we've been trying to solve for a long time is having instant DB resets between acceptance tests (in CI or locally) back to our known fixture state, but right now it takes decently long (like half a second to a couple seconds, I haven't benchmarked it in a while) and that's by far the slowest thing in our tests.
I just want fast snapshotted resets/rewinds to a known DB state, but I need to be using MariaDB since it's what we use in production, we can't switch DB tech at this stage of the project, even though Postgres' grass looks greener.
You can easily customize Caddy's browse template to your liking. It's just a text file, you can take the default and modify it, or write your own from scratch if you like. See https://caddyserver.com/docs/caddyfile/directives/file_serve... Some users have posted theirs on the forums as well if you need more inspiration.
Yes, for Caddy v0, which is no longer relevant because Caddy v2 was a rewrite from the ground up. No issues have been opened by anyone who cares about this since Caddy v2 was released over 5 years ago.
Yes calling it a grudge is kneejerk, but no I won't apologize for it because of how intensely frustrating the prior discussions (and today's, no help to you) were to deal with (take today's, multiply it by two for the intensity, then multiply it by ten for the amount of times it happened). You aren't me, you don't know what I've experienced and you don't know all the details, so please stop making assumptions.
I thought I was clear enough about this already, but clearly not: I encourage anyone who believes there's a bug with Caddy to report it to us on GitHub, where bug reports belong, where we can have focused discussion about it and see it to its natural conclusion. I do not discriminate bug reports based on who makes it.
An HN thread is not the place to report a bug. Nor do I think it's fair to form opinions about project maintenance (which doesn't happen on HN) based on comments in HN.
IMO a big reason is simply because they're written in C, which greatly slows down progress due to having to write a lot more code to do the same thing as higher level languages, and having to take significantly more care about memory safety issues. Caddy and Traefik being written in Go inherently solves both those problems, in addition to being built on top of Go's fantastic http and crypto stdlib packages which does the vast majority of the heavy lifting for implementing a compliant server. The remainder is mostly the config layer and middleware/admin/compatibility pieces (oversimplifying of course) which is where we can spend all our focus, being freed from having to be concerned about protocol level stuff (for the most part).
Admittedly there are some decisions we made with Caddy v2.0 that we would like to revisit eventually with a Caddy v3.0 in some future, but we haven't gotten to the point we've felt the need to plan that, most of those issues are minor enough that they haven't been deal-breakers. (And for context, v2.0 being a rewrite and rearchitecture from v0/v1 was necessary to unlock the potential that Caddy has realized today).
And you're still locked into this idea that you'll convince me that I shouldn't care, when I've expressed how it makes me feel due to the history. Can you respect that there are topics I'd just like not to be reminded of in a certain way? If it was brought up in a _constructive_ way, I would accept it (i.e. offering help or a solution via a PR with tests). If it was brought up by someone who I didn't specifically interact with negatively on this topic before, I would accept it.
> I believe that, but I also believe your attitude is a bigger threat to security than either.
I can't change your belief, nor do I care to, but I think that's absurd. Show me an actual security threat relating to this and I will address it. But this problem as stated is not one.
It's the fact they bring it up again when we've made it clear our stance is the problem, not so much the actual words in today's post. It's also off-topic (not relating to project maintainership) and it's on a post I submitted myself to HN.
I know you've already made up your mind, but look at our track record of answering support questions on the forums and tickets on GitHub, and you'll see that the picture you've formed in your mind from this thread is not accurate.
Those comparisons are very straw-man and I won't entertain them. As I've already said, IMO there's more risk in introducing a new security bug in trying to fix this issue than there is leaving it as-is (failing fast and hard).
We're perfectly within our rights to express how it makes us feel for it to be brought up, especially with the history we've had around it. It's caused us a lot of grief and we'd just like for it to stop being shoved in our face. That's all. If it was brought up by someone totally unique (not repeated by the same person as before, who we've already answered) then I would have had a different, more tactful response.
I really don't think it's fair for you to make a judgement on me or the project from an interaction like this. At least judge the project on its technical merits. I've been very transparent here. But I can't stop you from having your thoughts. It is what it is.
Caddy doesn't hit the front page of HN all too often. But when it does, this issue gets brought up by one of two people. That's why it's annoying. It's so predictable and so annoying. We've already said our piece on the topic repeatedly, being asked to repeat ourselves again is insulting to us. Because "this is low priority and we have no plans to fix it in the immediate future" is clearly not an answer for someone who cares about this issue and mentions it again.
If you haven't seen the history of this topic outside of this thread then you wouldn't understand how frustrating it's been to handle. I'd just like it to stop being brought up (without also offering help or a solution). Seriously, every time we either post something on HN ourselves regarding Caddy or find a thread posted from someone else, one of the first thoughts is "oh boy, are we gonna have to find issue brought up again?" Lo and behold, it was brought up again today.
As a core contributor, Matt has expressed on many occasions he would like to be able to pay us for all the time we've spent on the project, but I've always told him we're doing it as volunteers and not for money (my day job pays me sufficiently) and I think he needs it more since he doesn't have other sources of income. And if he did get enough from sponsorships to pay a second salary, I think he should hire someone not already a volunteer to broaden the skillset of the team. One of our biggest problems at this stage is that the members of the core team don't have expertise in a few specific areas that Caddy is lacking in (e.g. metrics/prometheus stuff)
Two people don’t make a conspiracy. And honestly, the tone came off as pretty snide. Quoting part of the post just to twist it into their own point was clearly deliberate.
I've read every single Caddy forum post (up until some months ago where I decided I had to slow down for my mental health), every single Caddy issue in the past 7 years, and nearly every thread mentioning Caddy on HN in the a similar time span, and it's only ever been brought up on HN by exactly two people. I know the patterns and I know how to find those comments. You may be talking about threads not relating to Caddy, in which case I don't find that relevant.
We've not seen a good enough argument that it's worth our time investigating. This seems like something that only affects something like 0.00001% of users. It may be simple, but it also means extensive testing to make sure any kind of fix doesn't also break other things. With how extensive Caddy's usecases are, we have to be careful with any change, especially low-level ones involving TLS and host matching. We could accidentally introduce somekind of request smuggling security bug for example if proper care isn't taken.
Why would we work on something we don't care about, for free? If they paid a sponsorship, that would allow us (moreso Matt) to spend the time looking into it. Or, people complaining about it can spend their own time finding a solution rather than making noise like this. (Also - I didn't "pore over", I simply searched for "caddyserver.com." in HN's search and it turned up every time two specific individuals brought this up)
We've felt attacked by people trying to slander the project due to this specific technical issue. It's exhausting. Either way, like I said, we'd be glad to accept contributions to solve this.
Still, only you and one other person with a similar grudge have ever complained about it (we've never had any github issues opened about it in years, neither on our forums) and nobody who cares has attempted to solve it with code changes.
We get it, you have a grudge. No need to post this comment every single time anything related to Caddy is posted on HN. PRs welcome if you want to propose a change.
We plan to move layer4 into the standard Caddy distribution eventually. We're still stabilizing it, and once we're happy with it (and have the time and energy to) we'll bring it in.
I am well aware of the risks. But I much more highly value getting bug fixes earlier rather than waiting a whole two years with partially broken software. As evidenced by the fact that everything I need to work does work now, and all the problems I had before have suddenly disappeared. LTS is overrated IMO.
They took too long so I moved off of PopOS 22.04 over to Ubuntu 25.04. I had tons of audio stability issues among many other things that I wanted fixed as well. I also have a lot of Gnome extensions I depend on right now, so I'm not ready to run a completely new DE without a healthy extension ecosystem to fix the quirks. I love the idea of a Rust DE and all that, but I can't really risk it for my daily driver machine.
It's not political so much as people of color want to use emojis they identify with, and it's very common for them not to identify with yellow because it's so much further from their own skin tone than yellow is to caucasians and asians
As we repeat every time this comes up, this was literally 8 years ago when the project was in its infancy and the project author was in the middle of exams, and it has not been true since. Caddy has been rewritten from the ground up since then, and comparing it to those old versions is dishonest.