Linux users can’t even agree […] so how am I supposed to pick one with any confidence?

Easy. You make a post like the OP, count the positive mentions of distros in the comments, and bam, you have your distro of choice. It’s called the Linux newbie roulette and works kind of like the magic hat in Harry Potter that sorts you into your house.

For the unfamiliar: https://www.youtube.com/watch?v=TJYOkZz6Dck

(CW: gore, subtitles)

Not yet, but you probably will be able to in the future.

Right so WhatsApp and messenger are gatekeepers and they must allow interoperation with who anyone who wants to ie me running my own signal instance?

There are several stipulations on interoperability in the new regulation (Ctrl+F “interop”). To my understanding it is stipulated that they have to make interoperability possible for certain third parties, but how to go about this is not exactly specified on a technical level - meaning the specific way to implement this is left to the gatekeeper. So your Signal server may or may not be able to depending on how exactly they go about this.

They also need to interoperate with signal hence if a works with b and c works with a why wouldn’t b work with c?

No they need to enable interoperability period. Says nothing about Signal (the software) per se. Meta has announced they plan on implementing it based on the Signal protocol (not Signal messenger software, not Signal server software).

Cos if thats hoe it works or if im not allowed to interoperate with WhatsApp or messenger in the first place then this juat seems like its handing the monopoly away from the companies to the government and giving the people fuck all.

To my knowledge the aim of the regulation is exactly that, to allow anybody interoperability with these “core platform services”. The status quo is that the regulations has been announced by the EU, it has gone into effect, and Meta has announced how they will implement interoperability to comply. Once the implementation is available and then found lacking in regard to the regulation it would be up to the affected third party to sue Meta over it.

In Germany, Mein Kampf is banned except for educational purposes, eg in history class.

Strictly speaking this is incorrect, although the situation is somewhat complicated. There are laws that can be and were used to limit its redistribution (mainly the rule against anti-constitutional propaganda), but there are dissenting judgements saying original prints from before the end of WW2 cannot fall under this, since they are pre-constitutional. One particular reprint from 2018 has been classified as “liable to corrupt the young”, but to my knowledge this only means it cannot be publicly advertised.

What is interesting though is how distribution and reprinting was prevented historically, which is copyright. As Hitlers legal heir the state of Bavaria held the copyright until it expired in 2015 and simply didn’t grant license to anything except versions with scholarly commentary. But technically since then anybody can print and distribute new copies of the book. If this violates any law will then be determined on a case-by-case basis after the fact.

Not with Signal messenger, the company running it hasn’t been designated as a gatekeeper under the DMA rules. You can see which services will be affected on the Wiki page (only WhatsApp and Facebook Messenger currently).

Signal protocol ≠ Signal messenger

AFAIK you could always have selfhosted a Signal server, you just can’t interact with the “normal” Signal messenger and its network.

No, the DMA has nothing to do with RCS, at least not directly.

Yes, WhatsApp and Facebook Messenger were initially just XMPP servers, but have since had proprietary expansions.

In the context of the DMA both of them will be forced to make interoperability with other third-party messengers possible, since Meta has been designated a “gatekeeper” under the new regulation. Meta has announced they plan on doing so via an implementation of the Signal protocol.

There are some provisions in the Digital Markets Act that go in that direction. It only took effect roughly 3 months ago though, so remains to be seen if it works out as intended.

pet open source projects that no one else ever seems to contribute to, not […] software that holds up civilization

SamePicture.jpeg

I’m involved in the development of an addon for the Classic WoW versions (Questie), and the thing I do there is such a convoluted process that not doing it feels like letting my fellow devs and the users down. But you can do development on the PTRs and beta servers, so I haven’t given money to Blizzard in a long time. Now you could argue that this is even worse in regards to supporting Blizzard than just paying for a game, but I rationalise it to myself with the fact that the newer clients will inevitably be used for private servers just like the old ones were (some already are actually).

Neither. Battle.net is Blizzards game launcher and store. They also own that domain, but the name usually refers to the binary.

The WINE_SIMULATE_WRITECOPY=1 %command% is the Steam launch option you set, with %command% meaning roughly “what Steam would do without any launch options set”.

The whole process was a bit finicky and I did it a few month ago, but from what I remember it went something like this:

• Download battle.net installer
• Add it as non-Steam game to run it
• Locate the newly created prefix in Steam directory
• Add the Battle.net.exe in it as a non-Steam game, then remove the installer (not the other way around or the prefix will be deleted)

Oh so that’s what you meant. Thought you meant don’t use Lutris at first because of how you worded it. That makes much more sense.

AFAIK you can set Lutris up to use GE or Proton builds.

Did that too a while back, but anecdotally it feels lees buggy through Steam, especially regarding updates.

Also clicking the Stop button in Steam doesn’t leave behind zombie processes off Battle.net.exe and Agent.exe, which I had to manually kill when using Lutris. Assume that’s due to Protons(?) pressure-vessel thingy.

It seems like it would be a bit confusing, though, if you had to relearn times whenever you travel somewhere (edit: and dates could flip over in the middle of a work day). But maybe you’d prefer that.

I’d prefer that over having to change clocks when you travel, and having to have knowledge about the location and possibly having to flip the date when you encounter a reference to a specific time, yes.

Before they were invented, it was literally just anarchy. People set it to match people they knew. That’s what I was thinking of, but it could also just be one place where noon is at 12:00 PM.

Yes, you would obviously do the latter. No sense it going back to the bad old days.

Well, there’s not a round number of second in a day, or days in a year, for example, since they’re all naturally occurring and arbitrary.

Days in a year ok (except leap years). But seconds in a day are round (discounting days with leap seconds). 24 * 60 * 60 = 86400, which is divisible by two. Did you mean they are not based on the decimal system? I’d be up for a decimal based time system and a reorganised calendar, but that wasn’t the topic of discussion here.

And then the Earth turns at a subtly non-constant rate, and people have settled on a seven day week.

Yeah but none of that has much impact on the timezone debate.

If you do have timezones, it doesn’t make sense to be inflexible with them when they run up against geography or trade and cultural ties, so they’ll be curvy, and geopolitics will itself change over decades and someone will want to change which one they’re in.

Fair enough. I acknowledged this point in my other post, that there are historical reasons for timezones mostly rooted in administrative requirements. But I don’t think this is a good reason to not adopt a better system per se.

All of this is a headache if you just want to do a calendar calculation.

Exactly! So out with the old, in with the new. Sure this will create some other headaches, especially given how deeply rooted some of the relevant nomenclature is in most languages, but the sooner we change this the less it will hurt. I see that it might be a non-starter given the inertia and disunity of globalised society working against it, but it still seems desirable nonetheless, to me at least.

I don’t think you could ever change my mind.

Fair enough, I still think you’d get used to it if it were to happen.

And when it does happen it’s usually clarified. In more automated contexts (e.g. a scheduled YouTube premiere) the software converts it automatically - the author inputs the date and time in their own timezone, and viewer sees the converted date and time in their own timezone.

My point exactly though, this is a whole lot of complexity we could just get rid of by using a single timezone, with the added benefit of that working without any automation or clarification. Next Tuesday 14:00? Same time for everybody, regardless of locality. Everyone will know what part of the solar day that is for them by habit.

When it does happen it reminds us that the date and time falls on a different time of day for different participants.

The complexity of coordinating different solar cycles is there either way and unavoidable. So why not use the simpler system?

Meet me here tomorrow at 01:00

Yes, semantic drift in these terms would be unavoidable, but I still see the long-term benefits to clarity outweighing the short-term costs in it.

We already have that for technology to use - the unix timestamp.

A unix timestamp is an offset to a UTC date, not a timezone. But fair enough, there is UTC. It’s not used by default however, except by scientists and programmers maybe.

Maybe I’m missing something. What do you think the benefits would be?

Removing ambiguity from casual language. Currently when you state a time you are almost always implying your local timezone applies, which might be unknown information to the recipient, especially with written sources like these comments here. With everybody using the same timezone instead you would always make an unambiguous statement about the specific time by default.