1337shadow

Just make sure that all your drug users do actually dismantle their guns before they take any! People are responsible as we all know, especially in our modern society where we value our own individuality above society, ie. "I can use drugs safely every once or twice a year, as such I want it easier for me to get some, and that's why I'm asking to make it legal for everybody, no matter the disaster we know drugs cause on a society". It's indeed exactly the same, "I want to hide my messages with my mom from my government so I will fight to prevent the government from being able to decrypt any message at all no matter the basis of the court order, no matter how many children have been raped or killed, I value my own freedom above security of society".

Basically, "the victims don't matter as long as I'm fine".

That's exactly why the law was not outlawing encryption at all:

> the proposed passage that would have forced companies to decrypt encrypted data upon request by the authorities got removed from the draft law.

I guess the article is pretty confusing.

And you'd rather have criminals that we can't catch because evidence is encrypted running around in the same streets as your children? Nobody's saying this law was a silver bullet.

It's not even an "encryption ban law", that's fake news.

> the proposed passage that would have forced companies to decrypt encrypted data upon request by the authorities got removed from the draft law.

Yes, I'm sorry I thought my second sentence was so stupid it would not be taken seriously...

Citing two different passages from the article:

> This draft included a passage that would have forced companies such as WhatsApp and Signal to decrypt their encrypted chats upon request by the authorities for criminal investigation.

> Belgian intellectuals like Professor Bart Preneel said that "by putting a backdoor into Whatsapp, you would make it less safe for everyone".

This does not look like a solid point to me; it looks like rhetoric. Anyway:

> a backdoor - once it is built - is abused by criminals or undemocratic regimes.

If they can get their hands on a governmental private key, which is unlikely.

> it is better to let someone guilty unpunished than it is to punish an innocent

Which is exactly what the law was for: to make it easier for enforcement to get more evidence.

This has nothing to do with mass surveillance:

> This draft included a passage that would have forced companies such as WhatsApp and Signal to decrypt their encrypted chats upon request by the authorities for criminal investigation.

As such, I don't understand your point at all, sorry.

Actually, shooting is a sport that isn't meant to hurt or kill. Drugs are great for society, doesn't matter how much they hurt and kill.

This is what they are talking about:

> a passage that would have forced companies such as WhatsApp and Signal to decrypt their encrypted chats upon request by the authorities for criminal investigation.

Because there are so many of them we don't have time to bother honest citizen, except on the road but that's for the money :)

Not if we catch them before they learn the lesson!

Let's legalize guns and drugs then! and party!

Unban guns while you're at it, they are useful too.

Yes you will, but most criminals won't, that's my point. It's exactly like legalizing guns.

That this reduces security for honest citizen, because it makes it harder to find evidence against criminals.

Because we should all think like you? Not me, I'm dissident from your mainstream ideologies, but have been fighting on your side for ~15 years ;)

What makes you think that exactly? I believe these people cause damage, often irreversible, and that crypto protects them. A proper cost/benefit study has not been taken here IMHO!

Did you try uwsgi? I have been hosting everything with this thing for over a decade and I still love it: https://uwsgi-docs.readthedocs.io/en/latest/Ruby.html

Hardcoding the python version from the start, not for me ...

Nice! But why do they always make code comments in a color that's so discret it's barely readable?

Populism being the point of democracy or am I missing something? How can that be "often to the same end" than totalitarism?

Actually you can already override __import__ and implement this, but then you still need an installer, and distro support for multiple instances of a same package.

> Packages go into abandonware all the time, removing version pinning doesn't fix that.

Abandoned dependencies should be treated like dropped features: re-implement them in your own code or create another library.

> Thank you for telling me this, I will be relaying to my clients that they need to upgrade their systems to newer Python versions to get new features, surely that will go well.

Very funny, but seriously they should have an upgrade path, or install their machine once and then never do a single upgrade, but again I'd say this is just tech debt piling.

> Waiting to release on new dependency versions until those versions are tested is not tech debt.

Not having your own tests is tech debt thought. I wouldn't rely on tests made by others.

> I mean, semantic versioning was done with this purpose precisely: to signal which upgrades are just bug fixes and you should upgrade ASAP

Of course I agree, the problem is that maintainers tend to not upgrade as often as they should, like until they really have too (another dependency upgrades a shared dependency). Again I see this as a maintainance problem rather than a package manager problem.

> If living at latest release works for you and dealing with dependency issues on new installations is not a problem, then go.

I'm not saying I never had a problem of course I do, I'm saying that having these problems has a better cost/benefit ratio at the end of the year, because: 0. they are smaller, dealing with one BC break at the time, and 1. they are spread over time because I integrate upstream releases continuously instead of waiting for the day I want to upgrade everything.

> "oh, it's just that this dependency released a new version that broke things and we didn't specify the version that our software needed"

I'd rather say "oh, it's just that this dependency released a new version that we are implementing support for as we speak, here's the command you can run to fix it meanwhile: ...".

But if you don't want to have that problem, just run your CI periodically, make sure the first thing you do in the morning is checking that nightly did actually pass tests, as you're talking about paid software maintenance, I'm talking about both paid and volunteer so that's why I'm including "wait for a user to report" but that doesn't apply for paid maintenance of course.

For me we're seeing the discussion between two fundamentally opposite approaches, one being defensive and the other being offensive / actual continuous integration. From my experience, the offensive strategy offers a better cost/benefit ratio at the end of the year.

> you can't be fully sure that upgrading everything to the latest version is not going to break anything.

Well, it's still what you do every time you create a new project.

> It is mandatory in quite a lot of package managers.

Ok but many packages won't be installable at all anymore, because people pin different versions instead of maintaining their packages by continuously integrating upstream releases.

> You can't live at latest release with software coming from wildly different developers, with wildly different policies on compatibility, versioning, breaking changes, bugs...

Well I didn't know can't so I did.

> I can't just take the latest numpy and patch it for Python 3.6.

Instead, you should be upgrading your code to support the newer numpy version. Seriously, try it out, you'll be spending less effort at the end of the year.

> You also spend time doing maintenance and debugging on new installations to debug and fix compatibility issues, when those upgrades might not bring any value to the product.

I spend less time and more spread over the year, bringing value to the whole ecosystem of packages which are bringing value to my product, and bringing value to myself as I develop new products with the dependencies I like and support as such.

> In my case, I do that debugging and fixing in a controlled environment

I wait for CI or users to report that a new release isn't compatible so I can fix it as soon as possible, in which case we temporarily pin versions, instead of piling up tech debt until it's so huge the whole project becomes trash.

That's what I call taking responsibility with the dependencies that you include in your product.

Exactly, the whole topic is about easing the process for Linux distro packagers right?

Silly, could just use another computer.

> Manage all dependencies there

Are you saying "put the different version of every dependency you need in there if you have to"?

Because I don't think package managers are ready for that, they usually like to have one version installed per package.

> That is impossible, it will never happen. Packages will have different maintenance cycles, some will get deprecated, others abandoned... You can't base your upgrade policy on an impossible situation.

You realize that if that was "impossible" and "never happening", then absolutely no Python environment would be working ever?

> A version conflict should be reported as an installation failure, not allow you to continue.

Please don't make this mandatory.

> Pip will install Y >= 2.0 and won't care that package X is now broken.

Fine, I'll just quickly fix X and open a pull request, like I probably did a hundred times, then eventually if necessary deploy my fork with the fix meanwhile they do their maintenance release.

Should we not take the responsibility of the dependencies we use and contribute back??

> The "live at master" philosophy only works for small groups of similar output capacity. It won't work for an ecosystem as wide as Python.

I don't understand why, but I'm talking about "live at latest release", not "at master".

> Sometimes it will be necessary, such as for example a package dropping support for a feature that another one needs.

Then the package can just paste the code of the feature in their own, until a new lib does it, I remember having to do that twice in 20 years (except I didn't just "paste" it, but implemented a much smaller version).

Overall, it seems my approach produces versions of my software and software that I depend on that are compatible with all versions because you can always use an earlier version if you really want to deploy on an old python or whatnot, whereas you approach leads to broken packages, tech debt, and blaming the package manager.

Interesting idea, we should be able to hook before `sys.modules` cache or make on of such cache for each module in Python then we should be able to produce this.

However, I thought the point was helping distro package management, which, to my knowledge, is not really built to support multiple installed versions of a package at the time: `dnf upgrade` for example, will upgrade all single instances of each packages to their newer release.

Ok but Go compiles statically, while you can do the same with pyinstaller, I don't think that's really comparable as we're talking about deployment right there.