melhor seria se o ativista de software livre não propagasse informações falsas que depõe contra o movimento que se pretende promover, ainda mais alguém com compreensão das manipulações e dos interesses capitalistas por trás dessas distorções... mas me pareceram enganos honestos. espero que ele tenha abertura (e liberdade 😉 para absorver alguns contraditórios, porque achei um email e mandei um contato. já tinha visto coisa dele antes e até tentado entrar em contato, mas a tentativa anterior foi infrutífera
those are dated already. I say we switch to one that provides the so-needed third intermediate state, and anyone who keeps on using the dated terms gets to be chastised and accused of being discriminatory (because blocking is often discriminatory) and of not keeping up with newer standards made up by others
yeah, I'm being intentionally sarcastic, because language policing like this often misjudges ignorance, inertia and rigidity as malice, mainly because it is manipulative and pushy to the core, regardless of any good intentions behind it. what people who are pushing for this replacement are saying is that black is now blocked and white is now allowed, which comes across as horribly racist to me. block is also a trigger word for me, because of my self-diagnosed PDA, so it's no good. and people who went violently after git repository maintainers who wouldn't replace master with main, and adopt the new nomenclature, don't seem to go after holders of Mastercard Black cards, or after Mastercard, with the same violence or vengeance, so to my autistic mind, it comes across as a hypocritical effort of beating up the weak while leaving the stronger offenders alone. not complaining about the meanings associated with red or yellow streetlights, despite their also being skin colors of discriminated populations, adds to that feeling: it's linguistic bullying with a seemingly-defensible excuse. holding people culpable for others' spurious associations is fundamentally wrong in my understanding.
sabe um pensamento que me deixou bem preocupado sobre essa novela?
a primeira foi ao ar em 1988, incitou ódio contra a corrupção, aí emplacaram o caçador de marajás das alagoas pra presidente, com direito a edição distorcida do debate pra não deixar o lula ganhar
já voltaram a usar a incitação contra suposta corrupção pra tirar concorrentes do páreo novamente depois, como LaFajuta, mas não descarto a possibilidade de que, com esse remake, estejam preparando o terreno para nova cilada
another point I don't get is whether you want the platform to reject participants outside of the scheduled meeting time. ISTM that ensuring the platform is there at the desired time is what it takes, and if it is available at other times, I don't see how that would hurt. but I'm not the one setting the requirements, I'm just trying to understand them to see whether GNU Jami would fit the bill for you. but really the only way to tell for sure would be by your giving it a try.
the one concern I would raise is that I don't know how big the meetings are. I haven't been to big meetings on Jami, and though it has worked superbly for 1:1 meetings even with my very old and slow and low-bandwidth computer (where no other chat system did), meeting 3 or 4 people at once was more than it (the computer) could endure. even more powerful computers may face trouble with very large meetings on Jami, though, because IIUC the party that initiates the group call becomes the one who receives the audio (and video) feeds from everyone else, and passes it on to everyone else.
so very large groups in GNU Jami could be as problematic as a very underpowered Jitsi server
GNU Jami offers some hope for that sort of features, that could presumably be added initially with its plugin architecture
that it uses per-conversation git repos with per-message commits underneath seems to make classification as simple as tagging the commits under some convention. that sort of thing would definitely be welcome to me. it's too easy to get things lost there.
I don't mean to invalidate your experience, but communication media are very much what we (and our communication parties) make of them. I find the asynchronicity of email generally welcome, but I've also been in very high-bandwidth email communications, and some people expect immediate responses; I've also been in very low-bandwidth chat groups, but the interactivity can be useful at times. the very same social media networks can be overwhelming or desertic, depending on your contacts, and on what you use it for. in my case, missing an email can be a problem, but missing a chat message is no biggie, so "catching up" can be as easy as "mark it all read" (if there are even such markers in the chat client). but while some people use chat for throw-away conversations, some run businesses out of it, and for them discarding chat messages could be as bad as missing an email or a critical notification. my observation is that the properties we tend to assign to these media are not inherent to the media, but to the customs of the groups we interact with through them.
I don't think I've come across this concept before. what are these "inbox rules" you speak of?
Jami, being Free Software, could probably have that and any other features that are desirable added. they don't even have to make sense for the business model of the original developers, and we're already at an advantage because Jami is not built with a goal of surveillance, control and exploitation
I'm told most people hardly ever look at their email these days. indeed, a lot of people don't even have one.
and they're not wrong. why use email that they need to go visit a web page to see, when a communicator like Jami brings messages, files and calls right into their devices?