Why am I not surprised.
this post was submitted on 11 Jul 2025
637 points (95.7% liked)
You Should Know
39716 readers
577 users here now
YSK - for all the things that can make your life easier!
The rules for posting and commenting, besides the rules defined here for lemmy.world, are as follows:
Rules (interactive)
Rule 1- All posts must begin with YSK.
All posts must begin with YSK. If you're a Mastodon user, then include YSK after @youshouldknow. This is a community to share tips and tricks that will help you improve your life.
Rule 2- Your post body text must include the reason "Why" YSK:
**In your post's text body, you must include the reason "Why" YSK: It’s helpful for readability, and informs readers about the importance of the content. **
Rule 3- Do not seek mental, medical and professional help here.
Do not seek mental, medical and professional help here. Breaking this rule will not get you or your post removed, but it will put you at risk, and possibly in danger.
Rule 4- No self promotion or upvote-farming of any kind.
That's it.
Rule 5- No baiting or sealioning or promoting an agenda.
Posts and comments which, instead of being of an innocuous nature, are specifically intended (based on reports and in the opinion of our crack moderation team) to bait users into ideological wars on charged political topics will be removed and the authors warned - or banned - depending on severity.
Rule 6- Regarding non-YSK posts.
Provided it is about the community itself, you may post non-YSK posts using the [META] tag on your post title.
Rule 7- You can't harass or disturb other members.
If you harass or discriminate against any individual member, you will be removed.
If you are a member, sympathizer or a resemblant of a movement that is known to largely hate, mock, discriminate against, and/or want to take lives of a group of people and you were provably vocal about your hate, then you will be banned on sight.
For further explanation, clarification and feedback about this rule, you may follow this link.
Rule 8- All comments should try to stay relevant to their parent content.
Rule 9- Reposts from other platforms are not allowed.
Let everyone have their own content.
Rule 10- The majority of bots aren't allowed to participate here.
Unless included in our Whitelist for Bots, your bot will not be allowed to participate in this community. To have your bot whitelisted, please contact the moderators for a short review.
Rule 11- Posts must actually be true: Disiniformation, trolling, and being misleading will not be tolerated. Repeated or egregious attempts will earn you a ban. This also applies to filing reports: If you continually file false reports YOU WILL BE BANNED! We can see who reports what, and shenanigans will not be tolerated.
If you file a report, include what specific rule is being violated and how.
Partnered Communities:
You can view our partnered communities list by following this link. To partner with our community and be included, you are free to message the moderators or comment on a pinned post.
Community Moderation
For inquiry on becoming a moderator of this community, you may comment on the pinned post of the time, or simply shoot a message to the current moderators.
Credits
Our icon(masterpiece) was made by @clen15!
founded 2 years ago
MODERATORS
Because people make mistakes and nobody is perfect and even paid software has problems?
Oh no, the secret plot of the tankies for world domination has been unmasked!
I really wish there was a way to enforce transparency of docker env vars.
I get that it's impossible to make it a part of docker, env vars get parsed by code and turned into variables. There is no way that docker can enforce it, cause a null/undefined check with a default value is all that would be needed to subvert checks by docker, and every language uses a different way to check env vars (eg .env files, environment init scripts, whatever).
And even then, the env var value could be passed through a ridiculous chain of assignments and checks.
And, some of those 'get env var' routines could be conditional. Not all projects capture all env vars during some initial routine.
I've spent hours (maybe days) trawling through undocumented env vars trying to figure out their purpose, in order to leverage them in docker/k8s stacks.
I wish there was something.
Thankfully, a bit of time spent with a FOSS project and reviewing the code does shed light on hidden env vars.
And a PR or 2 gets comments and documentation updated.
Open source is awesome
Yeah, I honestly just strongly dislike the whole Docker ethos. It was designed for one thing (deployment at scale), at which it excelled, and then everyone uses it for a different thing (reproducible one-off deployment), at which it is fine, basically, but just kind of the minimum set of capabilities to get the job done.
Nix can do what Docker does, in a much superior fashion (lower disk space, much better transparency, rollback ability, lack of towering chains of follow-on effects as you are talking about, and applications outside of mucking around with containerized images), but for some reason everyone uses Docker, and Nix is as far as I can tell unused outside of NixOS.
Whatever. When they make me king, it'll be different, that's all I can say.
Nix and Docker / container runtimes are completely different animals. Each is good at what they do, but those are vastly different things, with some overlap. If you want to share a kernel but use fewer resources than a VM, containers can do that. If you want to go further and completely isolate, you can use microvm’s like firecracker.
I don’t follow what is wrong with that. Maybe you mean it’s use where people use it specifically as a package manager. I agree with that, but even then it has its handy place.
Maybe you mean it’s use where people use it specifically as a package manager
Precisely. Containerization is great and Docker does it well. Sending someone a reproducible script that can set up your software package for them is great. Marrying the two concepts unnecessarily and using one specific tool which is designed primarily to do the first, to instead do the second, is the only real issue I’m taking with it.
You should edit your post with link to this PR - it's fixed now
Edited.
Thanks
This is fixed now.
Thank you for discovering this, and creating awareness around it.
Seems like a genuine miss, contrary to what the comments here would have one believe, given that the compose file (and rest of the docs) were mostly derived from whatever worked for the developers themselves.
Seems like a genuine miss, contrary to what the comments here would have one believe,
You might be right. I looked at the history and the way it came in, and it's not as wildly anomalous to the rest of the file when looked at in context. Maybe it's just a mistake.
if it was inadvertent you'd think someone at the receiving address would have spoken up....
load more comments
(1 replies)
ope, just gonna squeeze on through this minefield, dont mind me
That’s so on-character for .ml
The longer I look at it the more suspicious I am of it, to be honest. I'm just kind of generally a paranoid and accusatory person, so take that into account, but... the files are pretty carefully set up. They have variable substitutions for everything, including a bunch of places where there's a template substitution to change a string around when setting cache keys so that it'll still work out-of-the-box right away, even in complex configurations like multiple domains on a single server. It all works out-of-the-box right away, they've clearly been attentive to making sure it's all set up right and keeps working cleanly as things have been evolving forward. Except for that one place.
load more comments
(10 replies)
Was just gonna say. Exactly what some authoritarian boot lickers would do.
“Of course the Central Committee would have access to your instance. Why is that a problem? Are you doing something counter-revolutionary?!”
load more comments
(25 replies)
Why make a Lemmy post about this and not just a GitHub issue?
Why try to fix the issue if you can just farm some drama?
I think it should be more public knowledge than just people who peruse the github issues. Also, it's so trivial to fix that it will save them some time if they don't have to close the issue after they spend literally 10-15 seconds fixing it.
load more comments
(2 replies)
load more comments
(4 replies)
Good catch, seems like an oversight.
Bruh
Now I have trust issues with open source programs.
points glock at VLC Media Player
"WHO THE FUCK DO YOU WORK FOR? TRYING TO JUMPSCARE ME?"
💥🔫
💥🔫
💥🔫
💥🔫
💥🔫
💥🔫
I'm reminded of stories I've heard of graduate students hiding a note and some cash in the pages of their theses that they submit to the university, just to see if anyone bothers reading it and takes the cash. They return years later to find it still there.
With open source, the code is all there ready for review by anyone, as long as you have the technical knowhow and patience to review the code you use. But like reading the terms and conditions for everything we use, how many people actually take the time to go through all that code?
Some people do and at least you can, which makes it much better than proprietary software, where it is impossible to find out, if they didn't include a direct pipeline to whatever three letter agency asked them to do it.
load more comments
(1 replies)
view more: next ›