@bfiedler @kunsi Also ich hab sie als additonal-builtins deklariert. Aber es ist generell echt schwer, pylint beizubringen, dass der code geevalt wird :/ Und noch schlimmer: Es ist ja für jeden item-typen (auch custom items) der Pluralname als Dict-Variable vordefiniert. Eventuell sollte man direkt n pylint plugin für bundlewarp schreiben...
@kunsi Das kommt vom schwarzen Loch, dem nichts entfliehen kann. Oder sollte man das auch umbenennen?
@Juju Probably the same reason why people use euphemisms when talking about something unpleasant. Not naming it directly but describing it or using an abbrevation apparently makes it less triggerig to a lot of people.
@sir Alpine with a sway session needs around 5W idle on my notebook whereas Arch only needs 3.5W. I'm on the go a lot and battery life is a concern, so I rather live with Arch's stability problems. Tried to install it on an ARM board as well for a few hours and the kernel always hung when loading the initramfs. TL;DR: No Alpine for me, but it seems great
@kunsi Telegram für alles, was irgendwann mal Probleme gemacht hat (aber auch banales Zeug wie updates verfügbar)
git changing master to main by default
The argument against the word "master" is based on the unproven assumption that the term is loaded with racist connotations, and the mandate for change is based on the fact that the possibility of the assumption's truth is nonzero and that the side-effects of the change are small.
If that were true, I would be on board with it. However, it's plainly clear that the impact of git upstream switching the default branch name to "main" is going to be huge. Many scripts with the "master" hard-coded are going to break, scripts written on the valid assumption that the name "master" was an intrinsic, unchanging property of git.
Every programmer who works with repositories before and after the change are going to constantly mis-remember which is which, and we'll have to guess at the default when working with new or unfamiliar repositories.
This event is going to establish a new epoch in git. We should take that seriously.
Which means we have to confront the fact that the assumption (that inherent racism is present in the word "master" and is causing harm to those who have suffered under racism) may not actually be true. The claims do not hold up well under scrutiny. And, as far as I can tell, the cause is championed disproportionately by white people.
The moralized nature of the question puts an external pressure on decision makers on the git project, which is normally not present for other patches. They have to consider, if they review these changes negatively, will it affect their personal reputation? Their careers? If there's even a slight chance of this, is it better not to argue the matter at all, and rubber-stamp the patches? I don't think this change is being developed under the right conditions.
On the left, we have a tendency to rubber-stamp social causes with a lesser degree of scrutiny. I think that this is a testament to how much we value empathy and solidarity, but I don't think it's a healthy way to approach our problems. Software breakage has a social cost, too.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!