chclt's comments

People seem to conflate two things in this discussion: interpersonal issues (which are valid to talk about) and technical disagreements. Conflating these two can only lead to drama and reflects really poorly on the participants. Come on aren't we all adults here?!

Yeah, I think this is a solved issue. People just share physical media with the content they need. Which is more useful than this proposed solution, because they usually don't misguidedly respect copyright monopolies.

I still don't get what is wrong with the _ convention. Also please stop complicating the mental model of languages for no good reason (also looking at you C++).

god forbid anyone actually learns something at school

Because the working part of an organisation such as the one you describe tries to continually optimize away these restrictions. NPM (et al) is a good way to obfuscate the fact you're pulling unknown code to get shit done and processes haven't caught up yet.

I'm not saying this is good, but the reality with these company-internal restrictions is, that the most productive people find ways around them and are rewarded for it.

Are these the statistical parrots everyone keeps talking about?

> Git (and any merkle tree) already implements a tamper proof linked list, there’s no reason to burn electricity in a proof of work algorithm to accomplish this.

Thats why the word "and" is there in my sentence

Surprisingly, thats actually France.

Why are you getting so worked up about what is fundamentally a neat idea, which may or may not be used well?

> evading sanctions

The horror

Meh, being able to synchronise an append-only tamper proof linked list and control who gets to put what on it in a decentralized way is pretty cool. Not to mention it's far easier to implement with limited means, than 5nm chips, or large tansformer models.

(Also implementing money on it does seem pretty intelligent -- its a scarcity device -- peoble just seem to do stupid stuff with it)

In an ideal world stuff would be open and secure. But that doesn't seem to be happening.

99% of software IS malware for 99% of users

You had a very priviledged childhood then. The only response to my interests I got from my parents was "you are already good at school why are you straining yourself doing these unnecessary things".

And I did not have bad parents. Many actually hinder their childrens development, instead of being ambivalent to it.

What is has no relevance to what ought to be.

As a sibling comment to mine points out, people who "die or have their life destroyed" is simply one way to define victim in this context.

With mental health data being at stake here, the amount of victims under this definition could also very well be non-zero.

Anyway there are a lot of crimes, that don't produce those kind of victims. If I mug someone and don't kill them or destroy their life in the process, have I not commited a crime?

The privacy infringement here is an obvious damage to the dignity of everyone affected. Wouldn't you feel victimized if I listened in on you speaking with your doctor, wrote everything down, stamped your name, address, and date of birth on it and started giving out copies of the resulting paper to random people? Which is exactly whats happening here, except my example is more harmless by a factor of a few million people and has a lot fewer data points.

The people affected by the drug trade are not affected by the act of selling drugs but by secondary crimes (which arise because selling drugs is illegal and vendors cannot take advantage of the legal framework).

Also the people affected by this incident alone number in the millions.

Well thats the case for every crime.

And this one deserves (in my opinion) to be punished more harshly than other things which today are already punished (you mention selling drugs, which is way better morally). The amount of people damaged by this privacy infringement is quite high.

I think this highlights a deeper issue with how we as programmers tend to think about abstractions. It is easy to pretend, that you can conjure any interface/any abstraction from thin air as long as you define what you want well enough. But the reality is, that a good abstraction needs to be build using elegant constituent parts. It needs to be built in a way, which looks at the problem in an angle which simplifies it.

Building named sequences of source changes via commits which chain together, with the only thing that defines the identity of the chain being a ref to the end is such an elegant abstraction, which is not bad to expose; It allows for easy reasoning about source changes. Saying git branches are a seperate sequence of commits and keeping it at that would be not a good abstraction, even if you hid the implementation really well.

This seems to be more an issue with if statements without curly braces.

I have difficulty parsing out the actual substantial complaints about the fediverse in this article. The "I don't want to interact with some unpleasant people" problem seems to be already solved by killfiles and per-community moderation (as the author says). With this there of course come disagreements about who to peer with ecetera (as the author says). But this just comes with the nature of a federated system. What would be a better solution, downgrading again to having one higher authority?

The argument then seems to boil down to, that this does not lend itself well to marketing the platform. But this is a general issue with technologies, which require some thought to use (An unsolved problem, I suspect the issue lies with the people and not the technologies. Better education anyone?). Although the pointers on which language might better describe the thing when doing the social wrangling of marketing it seem quite useful.