timorl @timorl@qoto.org

So a few days ago I said I wanted to talk a bit more about the worldview behind that little book of 1980s lesbian feminist cartoons I have. Because it’s the kind of feminism I remember from when I was a student, and it’s the kind of feminism so many TERFs and their allies in the U.K. started with.

I’ll start with some scans...

Kadaif is a dessert made of strips of dough with crushed nuts, covered in syrup.

It's sweet, tasty, and delicate; just like your infrastructure if you don't use 2FA.

#TastySecurity #InfoSnack

After the violent events at the US Capitol the question isn’t how monopolist social media platforms should wield their power - the question is whether they should have such power in the first place.

We should break down the walls of social media monopolists, regulate them, and make monetising toxic engagement spilling into public discourse as onerous as dumping toxic waste into a river.

https://redecentralize.org/blog/2021/01/18/centralization-is-a-danger-to-democracy.html

Looks like Qt is over.

> The Qt Company has followed up on its plan to make long-term support releases commercial-only by closing the source for 5.15 today, earning protests from open-source contributors who say that the 6.0 release, which remains open, is not yet usable.

https://soylentnews.org/article.pl?sid=21/01/06/1338223

"Due to travel restrictions the US had to organise a coup at home this year"

Let's be very clear here: in no small part the blame for what happened today lies with surveillance capitalism.

It is *profitable* to put right-wing/fascist/conspiratorial content in front of more eyeballs, since it generates more "engagement". So Facebook, YouTube and others became perfect channels for this kind of crap.

Big Tech made money on this, for them today's insurrection is an "externality".

Finally, in 2020, #GCC 9.2.0 has been ported to #Jehanne.

Not a big achievement in the grand scheme of things, but still Jehanne is the first #Plan9 fork to run modern binutils and GCC.

http://jehanne.io/2021/01/06/gcc_on_jehanne.html

@freemo Python is used in a lot of places that it is not really all that well suited for. This seems to be largely because someone discovers how great it is with short, quickly coded, demonstration problems - which is where it is at its best - and then starts trying to use it for everything.

Now, it can *do* just about everything; and having a shorter development time is a solid advantage in a large slice of 'everything'. It's just that, once you get away from simple demonstration problems and into large, serious projects, then there are usually other languages that work out better; but even there, there's a very large category of problems where the difference might be fairly marginal.

So it gets used in a lot of places where it's not the best choice - because in some of those places, it's still a *decent* choice, just not the *best* choice.

@freemo I think that python is optimised for reducing *development* time. It's good for when you need to do something quick-and-dirty, the sort of thing where you need to only ever run it once or twice and you're really not going to be stretching the processing or memory bounds of the computer. The sort of thing where it's important that the code be readable, because there's a good chance that if you ever want to run it again, you'll need to tweak it a bit, first.

And in that narrow domain, it's really very good. But outside of that domain, it's probably not the best choice...

Been doing a lot of coding in python lately. While some of the hackability of the language is nice for doing some cool things, overall, I cant say im a fan. Its a little too obscured for writing algorithms where effiency is important. Its hard to tell what data types are truly backing various variables and thus makes it tricky to pick the right implementation. I think im working with raw arrays and they turn out to be linked lists or worse. Even then things like a "Dict" isnt always clear if its a Tree implementation or a hashmap implementation or something else entirely.

Granted this isnt an impossible task, I have managed to figure it out by pulling open the source code of the libraries I call and using profiling tools. But python seems to not care or obscures a lot of that.

#Python #Algorithms

Mit was überqueren Datenschützer*innen einen Fluß?

"As the tools of the marketing industry become the same tools that shape our democracies, political actors are adopting strategic approaches to #data collection and use that resemble those of corporate entities." Read our new article for @boell_stiftung@twitter.com: https://www.boell.de/en/2020/12/17/reflections-european-democracy-action-plan-easily-overlooked-concern

#freecad I'm trying to design some pretty simple shapes using FreeCAD (using Part Design and Sketcher) and I keep encountering weird issues, including things that look like caching problems (I need to twiddle a value back and forth to see effects of other changes reflected) and outright crashes (https://tracker.freecadweb.org/view.php?id=4523 and another that boils down to "this file crashes FreeCAD if I try to edit ~anything in it").

I am most likely using it in a weird way. However, I didn't expect that amount of issues (esp. crashes) even if I was using it completely incorrectly. Is it expected that FreeCAD will be crashy-when-used-weirdly, or maybe is it the fault of my distro (NixOS), or something else?

If only I didn't want chamfers, I would just use solvespace. Unfortunately, chamfers on non-side edges of extrusions are very annoying there.

Weird. On December 14th, #COVID recoveries count in USA in John Hopkins University dataset dropped abruptly to 0 (from ~6,3mln) and stayed that way:
https://rys.io/covid/#recovered,linear,date,average:7,from:2020-03-01;united-states,brazil,india,mexico,united-kingdom,italy

@freemo

Except those numbers are based on completely fictious numbers with no basis in reality…

I admit I haven’t tried to look them up now, these are just ballparks of lower bounds that I kind-of believe within the order of magnitude.

However, I realized that we should have a better way of estimating the risk of “dying from covid over a period of time”: we know (for many areas) how many people were diagnosed with covid and died as its result (for some definition thereof). For example, ~1/1300 of Switzerland’s population died of Covid since the beginning of the pandemic according to the official stats (https://www.covid19.admin.ch/en/overview?ovTime=total gives the number of deaths as 6003, population is ~8M).

Imagine a worst case ADE scenario, for example… in a year after the immune system has settled and everyone is in a state where theya re on long-term antibodies rather than short, now everyone getting COVID all of a sudden starts dying at 10x the rate as before due to ADE.. what was meant as a vaccine has now turned the disease into a far more lethal killer (basically how ADE plays out)… while we dont have the data to know this will be so, and we are completely blind as to its possibilities, the fact is, that is one worst case that could be absolutely horrific if it plays out.

Aren’t we similarly blind to the possibility of a Covid infection causing similar effects (á la Dengue fever)?

It seems to me that you’re suggesting that in face of two alternatives with unknown outcomes we should default to doing nothing. Do I understand correctly, or are you using some more specific principle? If so, why should we consider the “do nothing” alternative specially preferred?

I believe that there’s a good reason to treat “do nothing” as the preferred option when the alternatives are presented by an adversary (e.g. when someone gives us a “lucrative” offer under time pressure, a reasonable default action is to refuse; the “do nothing” alternative is the only one the adversary cannot fail to include). This obviously doesn’t apply here and I don’t think that outside of adversarial context this is a good principle.

EnD-tO-eNd eNCrypTed whaTsapP mEssAgeS