It should be noted that the malware bundling was done when SourceForge was owned by DHI Group, Inc. And now, for many years already, SourceForge has switched owners (BIZX/Slashdot). They have undone the bundling and are now trying to manage it like it was managed before. It seems like it's going well.
I would consider SF a viable Github alternative, but the bad reputation caused by a temporary owner just seems to stick forever.
Again, my point is not that FB Messenger will stop working in the web browser altogether. My point is that FB Messenger will stop working in the web browser if you don't have the FB Messenger app installed on your smart phone as the primary device.
Yes, and my guess is that they are planning on removing the standalone messenger from the web version. You'll probably need to have the FB Messenger app installed on a smartphone device in order to use E2EE. That would make it impossible to write messages on the web version (i.e. facebook.com) without having an app installed. I currently do not have the app installed and am able to write messages on the pure web version of FB on desktop. My guess is that they are enabling E2EE to get the last remaining desktop-only-and-website-only messenger users to install the app. Hope that cleared it up.
Given that E2EE messengers usually require being run on a smartphone as primary device, my guess is that they are trying to push the last remaining non-app-and-web-only users to their messenger app.
I can only seem to get the report for Germany. Here is the bot's reply (formatting omitted):
>No transparency report is available for your region. If any IP addresses or phone numbers are shared in accordance with 8.3 of the Privacy Policy[0], we will publish a transparency report within 6 months of it happening and will continue publishing semiannual reports.
>Note: for a court decision to be relevant, it must come from a country with a high enough democracy index[1] to be considered a democracy. Only the IP address and the phone number may be shared.
I have been using Tumbleweed for a few years now, but while it seems like a stable rolling release distribution, I am not quite sure about the "rolling release" part. Each month, a new snapshot comes out, which upgrades every single package you have installed, regardless of whether there were actual upstream updates. With a full Texlive installation and just a few more suites this amount to roughly 10,000 packages and over 5GB that need to be downloaded and installed each month. This a) kind of defeats the rolling-release aspect for me, b) takes a few hours, and c) feels like a cheat for the sake of stability.
Between those snapshots you might have bleeding edge updates for all the packages, but even then I do encounter package conflicts way too often. Well, on the upside, at least they are detected.
So yes, it is stable, but it comes at a price.
Apart from that, the community support felt mediocre, at least a few years ago. The most visited platform was a bulletin board forum with very little interaction. When I had trouble installing KDE, it took a few days until someone suggested the correct diagnostic tools. This is bad for being the testbed of a commercial distribution. In the end, I just installed Arch, which packaged KDE better than Tumbleweed did.
But on the other hand, maybe only if you use a distro long enough, you get to see the downsides, and each one has them.
If you're talking about Jitsi Meet, and to add another perspective: I have tried to install it and failed. Specifically, you could see that other participants have joined, but you could not see their video.
I have tried to set it up in different ways multiple times, following all the steps of the fantastic documentation meticulously, with full server resets in-between, researched the error messages thoroughly and even asked in the Jitsi forums, but there was just no way.
But if it works, it's a great piece of software that's easy to set up with really great documentation. I'm blaming the fact that it didn't work out on the hosting company (Strato) and their wonky VPS.
Flash games and animations often had a lot of static assets, like sound, bitmap images, or fonts. You could data-uri all that in your html file, too, but with all the base64 overhead it might be a good idea to compress everything afterwards (e.g. SingleFileZ, see my other comment). Of course only if file shipment is an issue for you, otherwise relying on your server's gzip compression might be enough.
Although there is no agreed upon standard for encapsulated single-file web content, you can try to run your finished product through SingleFileZ or single-filez-cli, and ship that around, or embed it with an Iframe. I'm just not sure if it's suitable for games or application that load static assets upon certain interaction.
Maybe I'm going out of a limb here, but wasn't the whole point of CSS to not have to touch the markup when changing the styling? Not trying to talk Tailwind down, I have just missed a lot of the evolution of web design in the past 15 or so years.
There's an error in the documentation. What's the standard procedure to submit a pull request or bug report here? The docs subdirectory just links to the website and I couldn't find them in the gh-pages branch, either.
* There is an own creation algorithm for each game, sometimes including parameters like difficulty
* For every game there must be only one possible solution. This means that you never have to guess. Otherwise, it's a bug. For Mines (Minesweeper clone), this is an outstanding feature.
* The solution for almost every game is implemented with a respective solving algorithm. You can learn a lot from the source code.
* Each generated game comes along with a seed which you can share with others, or for a bug report.
* The project cross-compiles out of the box for many platforms, including Android, Windows and Web. And the resulting Windows binaries are tiny, because it does not use a bloated GUI framework.
* It provides a well-thought framework in case you want to add another game.
* Icons of the game are created on-the-fly during the building process