Agreed, I run a 100+ member discord server for my WoW guild and so far both threads and forums are total dumpster fires that both go unused despite us trying to make them work. Slack's approach to threads is everything I want for Discord; I enjoy talking with my clients more on their Slack workspaces than I do talking with my guild on Discord just because the experience is so dismal on Discord.
> > After you get through this hurdle you then have to install the right software, and MSYS2 makes the "genius" decision of letting me pick which binary I want to install for every single install. Do you need to install fmpeg? Better spend an hour sifting through clang-amd64-ucrt-mingw32-ffmpeg vs. gcc-x86_64-w32-gnu-ffmpeg and tons of packages.
> Huh. Yeah, that does seem odd - is it a result of MSYS2 being oriented at devs who need compatible libraries?
Yeah, we are oriented at devs that re-package our binaries and also want to be a development environment for upstreams, and also a testbed for toolchains. So we provide x86/x64/arm64, then ucrt/msvcrt, and llvm/gcc. I wouldn't blame anyone for finding this confusing. It's described here: https://www.msys2.org/docs/environments
Pinning depends on the requirements you as the consumer have, and the specific package manager (pip, conda, poetry, etc.) so it's hard to give guidance that's helpful when you're a library maintainer. Generally when consuming any dependency you should pin though...
That's a good question actually. Given the complexity and power of iptables and nftables (which is the reason UFW, firewalld and the like exist) I'd guess probably not. Trying to determine if a rule on another chain (or really a combination of rules across a combination of chains) changes the behavior of one of yours would be... challenging. I suspect the best it could do reliably is detect that rules in other chains exist and warn about that, but that's also a pretty common case. Pretty much every VPS in a cloud would have this warning for example.
Personally I think the real problem here is docker. Injecting rules into iptables is a bit like blindly injecting lines of code into someone else's program sight unseen. I'm not aware of any other tools that are nearly so willing to do so.
This makes me so happy. Back when we had Jenkins slaves, one of our devops guys set a pipeline up that pip installed different versions over the top of system packages causing weird intermittent failures everywhere. Different pipelines would be running in different requirements files. I revoked sudo privs immediately for Jenkins (I didn't add them in the first place) and reprovisioned the whole build cluster resulting in pipelines breaking consistently where they should have been breaking: trying to do stupid stuff.
Personally I only ever use the system python packages on Linux if I can get away with it. Saves a whole world of problems.
> Back when we had Jenkins slaves, one of our devops guys set a pipeline up that pip installed different versions over the top of system packages causing weird intermittent failures everywhere.
Not everyone might like containers, but using them for CI seems like a good way to avoid situations like this, at least when viable (e.g. web development). You get to choose what container images you need for your build, do whatever is necessary inside of them and they're essentially thrown away after once you're done with what you need to do, cache aside. They also don't have any significant impact or dependencies on the system configuration either, as long as you have some sort of a supported container runtime.
Second containers (however controversial they may otherwise be). The official python Alpine container is < 20mb and the slim Debian variants are < 45mb. For many of my Python projects I end up needing to install various system dependency libs like CUDA, libav, libsndfile, etc. I tend to be a "fan" of containers generally and containers seem like the best way to handle situations like mine.
Nowhere in the official Python documentation (where 99% of new python users are going to go) does it warn or even talk about Linux and Debian specific issues like only using apt packaged versions of dependencies. It wasn't even until recent years that pip gave a hint or warning something might break in those setups. The situation with Python on Debian has been pretty bad IMHO with a cloistered group of people saying the status quo is just fine because it works for them exclusively.
"The situation with Python on Debian has been pretty bad IMHO"
The situation with anything has been pretty bad in Debian lately.
I'm all for the minimalistic approach in regards to Python. It's Ok to provide only the packages needed by applications and the core system. For everything else, there's pip.
EDIT:
I've meant to say, there's pip inside a venv.
I agree, the problem is if you just 'pip install foo' on Debian, like 99% of python docs and readmes say, it instantly fails. Worse yet if you think you should just elevate to root and force pip install to work you can potentially break the Python install. It's a nasty footgun.
Mixing pip with another package manager has always seemed weird to me. You're just asking for things to conflict and break.
I noticed with Homebrew that there was no way to untangle packages installed through pip and ones installed through Homebrew. After dealing with that mess once, I now make sure to use pip install --user. It can still cause things to break, but if that does happen it's at least easy to nuke the packages installed to my home directory.
Good. Now we just need to get pip itself updated so it refuses to run outside of a venv, and refuses to run unless invoked with "python -m pip" and we'll finally have something at least half decent.
And don't even get me started about how much better npm is at publishing packages, versus pip's refusal to add the same user friendliness.
PEP 704 is a recent proposal to require a virtual environment by default for any package installer - https://peps.python.org/pep-0704/. Again, you can opt-out if you want.
You could have a container whose entry point is a shell script that calls multiple Python programs that need different environments, or a multiprocess container that runs multiple Python programs, although I guess you could still address either by breaking down your containers differently.
I mean yes php.ini allows you to disable any function you want, and if you do that then this function doesn't work like expected, I can hardly blame php for that.
> assert() is still broken if it's disabled in php.ini.
Care to explain what you mean it's broken if disabled? That it is disabled (noop in runtime) so you're missing it? AFAIK that's the production setting. You should be able to enable it in build/test/ci/development, just how you want it.
Sure. (1) it is a global setting so I can't decide if I want it on a per application basis, with Docker that is less of an issue though (2) it is disabled by default, so hardly anyone uses it from what I see (3) I'd like to have it always enabled, also in production, so my code doesn't end up in states that I didn't expect and I get notified.
But that might just be me and/or my particular use case.
Only C extensions that themselves have no global state and don't depend on the GIL for locking, which most of them do. So they will all require some porting, and it will take time since it requires newer CPython API only available in 3.9+ and some even 3.11+ (PEP 630).
Imo that it's not phishable and that there is no secret on the target server is even more useful in practice. And both those properties don't require physical isolation.
To nitpick: s/there is no secret on the target server/the target server never sees the secret/
With proper password storage the target server never keeps the password. It course that is difficult to verify. With U2F the secret can't store a secret they can't see.
