- Hi there. I'm a brand new Traefik user. It's bundled with k3s, so I set it up for my homelab on a single node cluster. I'm a technology professional who has worked in infrastructure and software roles for more than 15 years.
I appreciate that you revised the docs, but I still found it quite difficult just to get started. My experience was poor enough that I almost switched to Caddy. The thing that kept me from doing that is that Caddy requires a custom container build for DNS-01 ACME challenges which I didn't particularly want to deal with. I found Caddy's documentation much easier to grapple with, so that could serve as some inspiration.
I have some feedback I'd offer of my own, too:
1. I'd recommend you take a look at the Divio documentation system: https://docs.divio.com/documentation-system/. Your documentation aligns to this vaguely, but I'd recommend reading about the different doc types and applying that feedback throughout the docs.
2. Traefik's tutorial and how-to docs are very dense and feel overwhelming. [1] Related to my first point, I think you're trying to provide too much information in the wrong places. Tutorials and how-to guides should be very focused and limit explanation to only that which is absolutely necessary.
3. Reference and understanding docs are mixed together. I'd recommend using an approach more like Caddy's, where the config reference (https://caddyserver.com/docs/json/) shows prominently what the expected config schema is, and all of the fields are explained briefly. If there is very nuanced behavior for a particular option, consider moving that to a separate reference or explanation page.
4. Having a few How-To guides for the most common patterns which include complete configurations would be helpful.
[1] Here are some concrete examples:
- On https://doc.traefik.io/traefik/setup/kubernetes/, there is a whole introductory session about setting up Kubernetes and I have to scroll before reading anything related to Traefik. It's not only unnecessary -- it's noise. Nobody is going to consult Traefik's docs for setting up Kubernetes, so just omit it.
- https://doc.traefik.io/traefik/setup/kubernetes/ and https://doc.traefik.io/traefik/getting-started/kubernetes/ are different pages which seem to explain mostly the same things. They both include too much irrelevant information, like overly explaining what Helm commands do. Similar to the previous point, it is not the job of Traefik's documentation to explain Helm to me.
- No, it wasn't always nebulous. Roguelike was a well-established genre for decades before it got hijacked and now means nothing.
Like all genres, games within the roguelike genre (or what some people call "traditional roguelikes") have some variance. But if you played two games in the "traditional roguelike" genre, you'd definitely feel the similarities.
These days if you pick two random games on Steam with the "roguelike" tag, you're going to get two experiences which are not even reminiscent of the other.
- I ran into one thing with jj that I would say is pretty bad. I love it other than the way it bit me in this one case.
I have a repo with some code that generates a credential and writes the credential to a location specified in .gitignore so it isn't picked up by version control.
I used `jj edit` to roll back to a change before the credential path was added to the ignore file to make an unrelated change.
The result? jj instantly started tracking the credential and I didn't notice it before pushing to GitHub.
Fortunately I did figure it out pretty quickly, but that could have gone very poorly.
See also https://github.com/jj-vcs/jj/issues/7237.
- I would strongly recommend you _don't_ get a Framework.
I bought one. It lasted less than a year. One day I pulled it out to use it and it just stopped booting. It had been barely used up to that point. No drops or anything like that.
Support was giving me the runaround, too -- by not using info I provided them, not answering direct questions, and asking me to provide info I had already provided.
Do some research on Framework support. You'll find it is atrocious.
The idea is absolutely amazing and I hope it succeeds. The expansion cards are an AMAZING feature. The problem is that the quality bar just isn't being met, yet.
- If you like Python, consider pyinfra.
- The number of people making the claim is not small.
You probably just cut all the people out of your life who disagree with you.
That is the liberal way, these days.
Donald Trump, among the worst presidents the US ever had, won the 2024 election. This kind of nonsense was absolutely a factor.
- I write a lot of shell and my advice is don't use plain POSIX shell. Write bash.
It is 2025. bash is present almost everywhere. If, by chance, your script is run somewhere that doesn't have bash then guess what?
Your POSIX script probably won't work anyway. It will be a different system, with different utilities and conventions.
Line count is not a good reason to choose or avoid bash. Bash is quite reliably the lowest common denominator.
I dare say it is even the best choice when your goal is accomplished by just running a bunch of commands.
All that said, bash is gross. I wish we had something as pervasive that wasn't so yucky.
- Isn't it interesting that your response here is questioning and perhaps dismissive?
If a minority were sharing their perspective about whatever their lived experience was with regards to racism, would you respond this way?
I'll answer that: no, you wouldn't.
Which very quickly lifts the curtain. The movement is not about empathy or understanding. It's about empathy and understanding for people you deem worthy of receiving it.
- One edge that PCs have is massive catalog.
Consoles have historically not done so well with backwards compatibility (at most one generation). I don't do much console gaming but _I think_ that is changing.
There is also something to be said about catalog portability via something like a Steam Deck.
- This video describes one: https://youtu.be/UJrdKKmb9tQ
- There is a reason that the old saying is "reduce, reuse, recycle". The effectiveness is in that order: reduce consumption, reuse what you have, and recycle what you can no longer use.
There is a very straightforward opportunity here for Apple to enable "reuse". They absolutely should be doing that.
- This article tries to provide cover for slamming DHH by opening with "this is a respectful debate".
DHH, like anybody else, is imperfect. But the author acts like he is superior. He isn't.
But I will say there is not much worse than a person who feigns respect and then goes on to say things like:
"toxic personality and inability to scale teams"
"it would be good to explore with a therapist or coach" (therapist really being the dig, here)
"Why are you still so small?"
"Instead of bragging about your beautiful office in the clouds, you should question why you can’t scale teams."
If your respect for DHH was real, you would have given your feedback in a respectful way instead of writing some blog post with such incendiary comments.
- > The dev secrets tend not to be as useful from the internet as they are from the intranet.
For many companies this is a myth.
Once you reach a critical mass of complexity and scale, you figure out that simple database seed files you can bundle into an app repo are not sufficient to test your application.
So what solution do people look to? Taking data from prod and feeding it into lower environments. Depending on what regulation you are subject to, some amount of data scrubbing may be required. But even if it isn't, leaking users' data is a bad look.
Is data scrubbing easy to do perfectly? The answer is 100% unequivocally no.
You mentioned intranet too, and the thing about that is making dev services available externally is a common enough problem that Ngrok is financially viable.
TL;DR: the assertion that dev secrets are low value is often not true.
- This article has about as much insight as I would expect from a "nodejs-security.com" article.
This article spends a good deal of time conflating two things: putting stuff in .env and using environment variables.
The application-parsed .env file is one of the most poorly thought-through ideas that has taken hold in modern application development. It takes something you can do in literally a couple lines of shell (as a container entrypoint) and adds a bunch of complexity for something that is actually just worse.
In local dev scenarios, app-parsed .env files suck because you often end up with some kind of dev-specific secret that you don't want committed to the app repo. In my experience this means developers figure out how to pass a .env file around.
If you use an actual shell instead, the local-dev .env can shell out to something like the AWS CLI to get secrets from parameter store. Or you could grab them from Hashicorp Vault if you run that.
And because a shell fetches it at run time, secret updates are seamless and properly access-controlled in one spot.
In proper deployment scenarios, .env sucks because your deployment system (container orchestrator, Lambda, etc) will need to set those values appropriately for their current environment anyway. And by having a .env file the app loads, now you have two places for configuration.
Applications simply should not have any involvement in setting values for their own environment variables. They are typically used for core infrastructure-level configuration. The source of truth for this is probably going to be available via something like Terraform. So the application should ultimately inherit they configuration through Terraform.
Additionally, this article is simply wrong on environment variables being readable by any user on a Linux system. On Linux, a process's environment can be read by the superuser and the user who owns the process. That's it.
- > Well it kind of makes sense if you believe people are generally going to follow social norms and not make false accusations for no reasons.
It kinda doesn't. If one in 10,000 people watching livestreams would do this kind of shitty thing, then at one million people watching livestreams, you can expect 100 instances of this crap.
It's small relative to global population but not small enough to ignore completely.
- What happens when you need to link a file that does not support comments like that? For example, something which stores its config as plain JSON.
Or how about when you want to symlink an entire directory? For example something like neovim, considering that you may want to split config into separate files for organization. My neovim configuration has an "autoload setup" so any lua files inside the config directory are automatically required.
Lastly, this approach does not appear to support running commands. My dotfile install script ensures that tmux plugins are installed, the terminal font I use is available, and some other stuff that you need to invoke a command or script to achieve.
I like that the approach is simple, but I do not think it can support even relatively common use cases very well.
- I have recently started making a concerted effort to eat better due to high cholesterol. My BMI is in the normal range, but at the high end of normal.
Given my recent experience eating better, I think junk is probably even worse than many people realize.
Refined sugars increase appetite astronomically. When I flipped to healthy food, I had a good few days of "suffering" as my body adjusted to lower calorie intake. After that, I never felt better.
My daily calories are something like 1/4 what they used to be. I lost 10 pounds in a few weeks without even trying. My mental clarity is coming back, which I thought slipped a bit due to age. Maybe age is a factor -- but diet fixed it!
- > The "OS" isn't special here, apps can listen to system audio.
Even if this is true, it's easy to imagine such functionality being exploited by malicious apps as a security and/or privacy concern, particularly if the user needs a screen reader.
It definitely makes sense for the operating system to provide this functionality.
- The fine doesn't even amount to a slap on the wrist.
It's like if someone stole $1000 worth of merchandise from a store and the only punishment is a $1000 fine... and you get to keep what you stole.
Why be law abiding when you could break the law and potentially make more money? You'd have to be stupid to be law abiding in a system like that.
- > Why shouldn't the burden of proof be on the people making these meal replacements?
So we can have what, one source on the issue with a very obvious conflict of interest? What kind of sense does that make?
> The NOVA system is more interested in the wider effect of ultraprocessed foods replacing existing eating and cooking habits.
I wasn't make a comment on what they do. I was making a comment on what I would find useful.
I don't find saying "ultraprocessed bad mmmm'kay" particularly interesting or insightful. All processes and preservatives are not equal. Pretending they are (or even just glossing over the details) is unscientific and a waste of time and money.
If people immigrate to America, the arrangement should be mutually beneficial.
We are not, and should not be, the self-appointed saviors of the world.