You're right! I thought about it as I was typing, that having a mechanism to evolve in the future is important! And both protocols can evolve over time
Though I think that the "Matrix evolves, server implementors should follow the specification" model/mentality may work better (even if not all implementations follow it, but most probably will)
Than the mentality of "the base XMPP protocol only sends text messages, everything else is optional, before joining a server and downloading an app users are advised to check if they support images, encryption, federation, and chat history synchronization"
It is far more productive to recommend, have a discussion and help develop alternatives, instead of pointing out that everything is just bad
[show a client whithout these problems]
These issues are at least solveable by a client though. The fragmentation that seems to be happening around XMPP however, is not. No one can do anything e.g. if half of the public XMPP servers (instances) don't support federation, or encryption, or images
That's true! I tried looking into using it because it seemed pretty good, but the fact that every simple little feature is a protocol extension is a flaw as well:
e2e encryption, federation, communities and community features (which are impotant points of focus for Matrix), even sending an image or an audio message, and synchronizing chat history (!) are not guaranteed to work on all servers/clients! I'm not sure if this is even possible on Matrix
[no good implementations because it may be poorly designed]
Same goes for XMPP π XMPP seems to be losing adoption (instead of feeling more mature) even though it's a 27 year old protocol, while Matrix (started in 2014) is gaining π XMPP seems to have ~3 clients on F-Droid (and their forks) which look like a default SMS app, while Matrix clients, SDKs, bridges etc continue to pop up on flathub and F-Droid
(I don't think these alone should be a reason to not use XMPP! I'm just mentioning it as an answer to your point. However, I think that the fact that image support is an optional after-thought of the protocol, shows the age of the protocol a bit)
(Also please correct me if I'm wrong! I haven't looked into it in a while, but the ecosystem definitely felt less consistent than Matrix's)
In any case, while good points can be made for either protocol, in the meantime centralized services (like Signal) are gaining adoption, which are not great things to rely on with Chat Control (etc) on the horizon π
We should try promoting, using, helping to develop anything we believe is the best and seems to have more potential and be more resilient!
I also like the work that's happening on SimpleX.chat (even though I'm not sure if it's going towards "Web3"-territory), since the distributed design and the privacy features (no UIDs, support for many profiles, quantum-resistant encryption) may prove more resilient to the Chat Controls of the future π€ At the same time it seems to have a more "centralized service"-feeling UX and user on-boarding, while in fact being less centralized
Matrix is a protocol. I too have these issues with Element (the popular Matrix client), but this doesn't mean that the protocol is bad.
This is like saying you hate HTTP or the Internet just because Internet Explorer is bad, or that the Fediverse (ActivityPub) is bad just because you don't like lemmy.today's default website theme.
UX problems are solved just by choosing a different client/website/mobile app. That is indeed an issue, the lack of more mature native clients. There are many ( https://matrix.org/ecosystem/clients/ ), but last time I tried to test them, some feature or another was missing :(
You're right! E.g. some story-heavy games with great mechanics and immersion might be worth spending more on; it's just a general rule of thumb I have!
(maybe it takes a bit more time for me to familiarize myself with the characters, controls, mechanics etc, so I don't prefer a game to be too expensive or too short; and in general I consider it a bonus if a game has huge replayability, support for mods, and procedural generation for example)
But in any case, I still find the ratio to be a useful tool!:
A game that seems pretty fun, at β¬1/hour it's a no-brainer to buy!
A game that seems kind of interesting but I'm not quite sure I'm going to like, at β¬3/hour I'm going to wishlish it and maybe check it out in the future
A very short game that I'm not quite sure I'm going to like but it's from a small developer, β¬2/hour I'm going to be a little hesitant but may think "hmm it's not too expensive, why not try it out and worst case I just supported a small developer who might make something I like even more in the future"
A game that seems beautiful with excellent gameplay, new and interesting mechanics, not released from a AAA company, at β¬4/hour it might be worth it
So the per-hour ratio is more about putting the prices of the games in some context between eachother, in order to be able to decide if <feature you value> is worth paying <X%> more than other games you buy; Every player and the genre of games they choose are different, so it makes sense for anyone to set a different amount as a baseline! π
I'm playing on PC (Linux PC + a Steam Deck) because it's a more open platform.
I avoid buying games that first came out as exclusives: if they didn't want my money when the game first came out, I'm not going to give it to them later either π€·
I generally prefer buying from smaller companies and indie studios
There are millions of other games from developers who do want my money, are cheaper, the money goes to developers and artists who need it instead of a huge corporation that lay off people all the time etc
Games are a form of art, and there are so many developers and artists that take the leap to try new things instead of pouring the same type of content in the same safe thing that appeals to more people and just sell more copies
Smaller games usually have way better VfM (I tend to prefer ~β¬0.5-β¬1 per hour of gameplay, but if it's a small studio I'm okay with paying a little bit more, given that steam+taxes take a little over 50% π« )
Depends on the system! Even for anonymous polls, you still need to have unique links to ensure that people don't take it multiple times and bias the results. Even if it can track who has (not) answered the poll, it doesn't mean that the answers are traced back to you!
If they want they still can track you though, so this is why we need tools that we can verify how they work, e.g. open source services, maybe hosted on a external trusted provider etc
Actually the Greek question mark (ΝΎ) looks like the Latin semi-colon (;)!
Last time I looked it up I think I found they are the same characters, and I tried compiling C with a Greek question mark instead of a semi-colon and it compiled fine! But I'm curious if it was because of something else, like my computer's keyboard layout, or the compiler simply being able to handle them π€
You mean the KDE Literature Optical Recognition and Identification System? It's just a plugin for skanpage that helps with book scanning and OCR π€· How else would they name it? (I just made it up)
I've been thinking, it'd be great if we had an AlternativeTo alternative, but open source and community-maintained π€ Right now any contributions we make are owned by that single company, with no way to e.g. make a fork if something goes wrong :(
Does anyone know if something like that exists?
(I know about awesome- lists but their use case is a little different, plus they're scattered across many different repositories)
I used to play "Subway Surfers" a little, but got tired of the gameplay being designed around microtransactions etc (similarly, for many other mobile-friendly web-based games on some websites)
I've also tried to find other similar runner games on Steam (again, I haven't found a favorite :( ), but unfortunately the Steam Deck can't always replace a phone in many everyday scenarios :(
Unpopular opinion: I like the concept of daylight savings: π
What's written on a clock is entirely artificial, made by humans to use as needed in everyday life; It doesn't matter what it shows, just that it shows the same for everyone
I think we should decide what we want it to mean (e.g. sunrise always at 07:00, middle of the day at 12:00, move the sunset based on concrete statistics that prove it would minimize energy consumption, or anything else we want), and implement it in small increments
In a world where 99% of clocks are digital (phones, smartwatches, computers), no one will care or notice if for 6 months every day they lose 42 seconds of sleep, and then for the next 6 months gain them back again; (computers that need a stable reference point usually use UTC anyway)
Heck, even without modern technology: Germany was broadcasting the time on a specific radio frequency with DCF77 like ~50 years ago, for synchronizing train station clocks, so today it should be more trivial than ever to make this change in the clocks and software that people use π€
You're right! I thought about it as I was typing, that having a mechanism to evolve in the future is important! And both protocols can evolve over time
Though I think that the "Matrix evolves, server implementors should follow the specification" model/mentality may work better (even if not all implementations follow it, but most probably will)
Than the mentality of "the base XMPP protocol only sends text messages, everything else is optional, before joining a server and downloading an app users are advised to check if they support images, encryption, federation, and chat history synchronization"
Can you please elaborate on that? π€
What would you propose using instead?
It is far more productive to recommend, have a discussion and help develop alternatives, instead of pointing out that everything is just bad
These issues are at least solveable by a client though. The fragmentation that seems to be happening around XMPP however, is not. No one can do anything e.g. if half of the public XMPP servers (instances) don't support federation, or encryption, or images
That's true! I tried looking into using it because it seemed pretty good, but the fact that every simple little feature is a protocol extension is a flaw as well:
e2e encryption, federation, communities and community features (which are impotant points of focus for Matrix), even sending an image or an audio message, and synchronizing chat history (!) are not guaranteed to work on all servers/clients! I'm not sure if this is even possible on Matrix
Same goes for XMPP π XMPP seems to be losing adoption (instead of feeling more mature) even though it's a 27 year old protocol, while Matrix (started in 2014) is gaining π XMPP seems to have ~3 clients on F-Droid (and their forks) which look like a default SMS app, while Matrix clients, SDKs, bridges etc continue to pop up on flathub and F-Droid
(I don't think these alone should be a reason to not use XMPP! I'm just mentioning it as an answer to your point. However, I think that the fact that image support is an optional after-thought of the protocol, shows the age of the protocol a bit)
(Also please correct me if I'm wrong! I haven't looked into it in a while, but the ecosystem definitely felt less consistent than Matrix's)
In any case, while good points can be made for either protocol, in the meantime centralized services (like Signal) are gaining adoption, which are not great things to rely on with Chat Control (etc) on the horizon π
We should try promoting, using, helping to develop anything we believe is the best and seems to have more potential and be more resilient!
I also like the work that's happening on SimpleX.chat (even though I'm not sure if it's going towards "Web3"-territory), since the distributed design and the privacy features (no UIDs, support for many profiles, quantum-resistant encryption) may prove more resilient to the Chat Controls of the future π€ At the same time it seems to have a more "centralized service"-feeling UX and user on-boarding, while in fact being less centralized
Matrix is a protocol. I too have these issues with Element (the popular Matrix client), but this doesn't mean that the protocol is bad.
This is like saying you hate HTTP or the Internet just because Internet Explorer is bad, or that the Fediverse (ActivityPub) is bad just because you don't like lemmy.today's default website theme.
UX problems are solved just by choosing a different client/website/mobile app. That is indeed an issue, the lack of more mature native clients. There are many ( https://matrix.org/ecosystem/clients/ ), but last time I tried to test them, some feature or another was missing :(
The same goes even for e.g. bugs in federation, since we have competition even on the server software! https://matrix.org/ecosystem/servers/
Do you have any technical comments about improvements that can be made on the protocol? π€ https://spec.matrix.org/latest/
"Value for money"!
You're right! E.g. some story-heavy games with great mechanics and immersion might be worth spending more on; it's just a general rule of thumb I have!
(maybe it takes a bit more time for me to familiarize myself with the characters, controls, mechanics etc, so I don't prefer a game to be too expensive or too short; and in general I consider it a bonus if a game has huge replayability, support for mods, and procedural generation for example)
But in any case, I still find the ratio to be a useful tool!:
So the per-hour ratio is more about putting the prices of the games in some context between eachother, in order to be able to decide if
<feature you value>is worth paying<X%>more than other games you buy; Every player and the genre of games they choose are different, so it makes sense for anyone to set a different amount as a baseline! π!stick@sh.itjust.works
Mine is a 200kB text file (I imagine much smaller if compressed into e.g. a zip file), so it could just be attached in an e-mail π€
We now have the technology
Depends on the system! Even for anonymous polls, you still need to have unique links to ensure that people don't take it multiple times and bias the results. Even if it can track who has (not) answered the poll, it doesn't mean that the answers are traced back to you!
If they want they still can track you though, so this is why we need tools that we can verify how they work, e.g. open source services, maybe hosted on a external trusted provider etc
Actually the Greek question mark (
ΝΎ) looks like the Latin semi-colon (;)!Last time I looked it up I think I found they are the same characters, and I tried compiling C with a Greek question mark instead of a semi-colon and it compiled fine! But I'm curious if it was because of something else, like my computer's keyboard layout, or the compiler simply being able to handle them π€
Btw Hedgedoc supports making reveal.js slides!
https://docs.hedgedoc.org/references/slide-options/
https://demo.hedgedoc.org/slide-example
You mean the KDE Literature Optical Recognition and Identification System? It's just a plugin for
skanpagethat helps with book scanning and OCR π€· How else would they name it? (I just made it up)I've been thinking, it'd be great if we had an AlternativeTo alternative, but open source and community-maintained π€ Right now any contributions we make are owned by that single company, with no way to e.g. make a fork if something goes wrong :(
Does anyone know if something like that exists?
(I know about
awesome-lists but their use case is a little different, plus they're scattered across many different repositories)Community declines Oracle proposal for using MySQL
(*radii π )
Thank you for sharing!
Do you have any other recommendations for such games? I've been looking for "mindless" games but I haven't had much luck finding any
I however have found "Breakout 71" which is pretty cool!
https://f-droid.org/packages/me.lecaro.breakout
https://breakout.lecaro.me/
I used to play "Subway Surfers" a little, but got tired of the gameplay being designed around microtransactions etc (similarly, for many other mobile-friendly web-based games on some websites)
I've also tried to find other similar runner games on Steam (again, I haven't found a favorite :( ), but unfortunately the Steam Deck can't always replace a phone in many everyday scenarios :(
Unpopular opinion: I like the concept of daylight savings: π
What's written on a clock is entirely artificial, made by humans to use as needed in everyday life; It doesn't matter what it shows, just that it shows the same for everyone
I think we should decide what we want it to mean (e.g. sunrise always at 07:00, middle of the day at 12:00, move the sunset based on concrete statistics that prove it would minimize energy consumption, or anything else we want), and implement it in small increments
In a world where 99% of clocks are digital (phones, smartwatches, computers), no one will care or notice if for 6 months every day they lose 42 seconds of sleep, and then for the next 6 months gain them back again; (computers that need a stable reference point usually use UTC anyway)
Heck, even without modern technology: Germany was broadcasting the time on a specific radio frequency with DCF77 like ~50 years ago, for synchronizing train station clocks, so today it should be more trivial than ever to make this change in the clocks and software that people use π€
π
(Turns out it does exist! But it's just a chemical https://en.wikipedia.org/wiki/Melem )