writefreely.debian.social

Reader

Read the latest posts from writefreely.debian.social.

from donald

#!/bin/bash

What to type here ... I'm not sure to be honest with myself as I doubt many will see these random entries of thoughts or progress. Nonetheless, here we start. I hope anyone reading enjoys an entry or thought or revels in this new adventure.

 
Read more...

from Rhonda D'Vine

Über den Text

Dieser Text erschien ursprünglich in der Print-Ausgabe 1/2022 des feministischen Magazins an.schläge. Um ihn auch anderen Leuten zugänglich zu machen, teile ich ihn hier.

Let's talk about Transmisogyny

Ich möchte mit Simone De Beauvoir einsteigen: “Du bist nicht als Frau geboren, sondern du wirst eine.” Hallo. Ich bin Rhonda. Ich bin trans und ich bin eine Frau.

Im Transitionsprozess wird von uns trans Frauen erwartet, die gesellschaftlichen Normen, die an Frauen gestellt werden, zu erfüllen. Sogar zu übertreffen. Damit dir geglaubt wird, dass du eine Frau bist, musst du also mehr „Frau sein“, als es von cis Frauen erwartet wird. Diese Krux bildet den Kern der intersektionalen Diskriminierung, die trans Frauen erfahren – weil wir sowohl Frauen sind als auch trans Menschen und wegen beidem diskriminiert werden.

Geht es um Transfeindlichkeit, ist es deshalb besonders wichtig, unsere Stimmen zu hören, also die Stimmen derjenigen, die Transmisogynie erfahren, denn nicht alle trans Personen sind auf die gleiche Art von Transfeindlichkeit betroffen.

Prominentes Beispiel: Die Autorin-deren-Namen-nicht-genannt-werden-darf (J. K. Rowling, Anm.) hat mit ihrer Aussage “Sex is real” transmännlichen Personen ihre Geschlechtsidentität abgesprochen, als sie sich über die Formulierung “Menschen, die menstruieren” empört hat. Eine Bezeichnung, die transmaskuline Menschen und AFAB (Assigned Female At Birth, Anm.) non-binary Personen einschließt, die ebenfalls menstruieren können.

Bezeichnenderweise hat die aufgeregte Debatte jedoch vor allem dazu geführt, dass trans Frauen transfeindlich attackiert wurden – auch die Autorin selbst richtet sich ihn ihrem Essay vor allem gegen trans Frauen. Denn die Gefahr, die in diesen hasserfüllten Debatten heraufbeschworen wird, basiert auf klar biologistischen Annahmen – sie soll von Penissen ausgehen. In dieser Logik ist jeder vermutete Penis ein Unterdrückungsinstrument patriachaler Strukturen, der die Gefahr von sexualisierter Gewalt mit sich bringt.

Mal ganz abgesehen davon, dass dadurch trans Frauen grundsätzlich Gewaltbereitschaft unterstellt wird, basiert diese Unterstellung auf so vielen falschen Annahmen, dass alle Alarmglocken schrillen sollten:

Nicht alle trans Frauen haben einen Penis. Ein nicht geringer Anteil von trans Personen hat eine bzw. mehrere sogenannte geschlechtsangleichende Operationen hinter sich.

Den Penis als Instrument patriachaler Gewalt zu definieren, folgt der heteronormativen Vorstellung von penetrativem Sex. Für genügend trans Frauen ist eine Erektion jedoch allein schon aufgrund der Hormongaben nicht möglich.

Zudem ist penetrativer Sex aufgrund der Dysphorie für viele völlig uninteressant. Das hindert transfeindliche Personen allerdings nicht daran, sich dieser Muster zu bedienen, um solche Bedrohungsszenarien heraufzubeschwören.

Eine weitere, wenig beachtete Komponente von Transmisogynie ist, dass im queerfeministischen Umfeld vor allem transmaskulinen Personen eine Plattform gegeben wird, transfemininen Stimmen oftmals jedoch nicht. Natürlich ist es wichtig, transmaskuline Personen einzubeziehen – allerdings frage ich mich, ob hier der Hintergrund nicht ebenfalls wieder ein biologistischer ist, aufgrund der vermuteten inneren Körperorganen sowie aufgrund einer unterstellten weiblichen Sozialisierung.

Sozialisierung ist ein Begriff, mit dem trans Personen ständig konfrontiert werden, der aber ausblendet, dass eine Sozialisierung nicht lediglich im Kleinkindalter passiert, sondern sich das ganze Leben hindurch vollzieht – insbesondere auch nach der Transition.

Transmaskuline Menschen können nicht über die Diskriminierungserfahrungen von transfemininen Personen sprechen, da sie nicht von Transmisogynie betroffen sind. Oder um es anders zu sagen: Die Transfeindlichkeit, die transmaskuline Personen erleben, basiert darauf, dass ihnen Weiblichkeit zugesprochen wird. Transfemininen Personen hingegen wird sie abgesprochen.

Beides ist scheiße, aber auf andere Art scheiße. Diese Unterschiede müssen im Queerfeminismus berücksichtigt und gehört werden.

Rhonda D'Vine ist im Vorstand des Vereins Nicht Binär, Aktivistin und Poetry Slammerin.

 
Weiterlesen...

from paddatrapper

I am one of the maintainers of LibreTime, an open source, online radio scheduling and automation platform. One of the features LibreTime offers is live shows via Icecast mounts. These allow DJs or admins to stream content live to LibreTime that will then be played out instead of the scheduled media in real time to listeners.

Icecast mounts are great for a single person connecting and streaming content. They do not support multiple sources connecting at the same time. This makes bringing in a second DJ or guest difficult, as the group connection needs to happen before the Icecast source connection.

Mumble is an open source group audio chat application that allows users to connect and interact in rooms that can be linked together in a variety of ways. It is available on every major computing platform – Windows, OSX, Linux, Android and iOS and can be configured to imitate a studio environment so that DJs and guests are comfortable in some of the aspects of what is going on. Mumble also supports bot accounts, these bots can connect to the server and do a variety of things, for example play audio into a room or stream audio from a room to somewhere else.

I spent the last month or so developing a system that would allow people to stream a Mumble room to Icecast so that DJs and guests could participate remotely in a Mumble show, while streaming out to Icecast. The implementation includes a Mumble bot for playing out media from the LibreTime library, allowing radio stations to control what is going out on air.

Implementation

This implementation uses the following components:

  • Mumble – used for presenting the show
  • Botamusique – used to play media from LibreTime's library into Mumble
  • MumbleIce – used to mix together the Mumble audio streams and to stream that to Icecast

The Mumble server is configured to require a server password and has 2 rooms under root: Studio and Off-Air under that. Studio and Off-Air are linked, with ACLs preventing people in Off-Air from speaking in Studio. This allows DJs and guests to talk to each other during music breaks, while still being able to hear what is going out on air. Both Botamusique and MumbleIce bots are configured to join the Studio room.

Botamusique is setup to run on the same server as LibreTime. I use LXC containers, so I mounted the LibreTime library into both containers. In the Botamusique configuration, I disabled the ability to delete media, disabled the ability to upload media and changed the command symbol to #. The last option was to avoid conflicts between botamusique and MumbleIce.

MumbleIce runs on my Kubernetes cluster and the configuration is mostly default. The Icecast credentials are those required to connect to the master mount in LibreTime.

To present a show, the DJ simply joins studio, types #web into chat to get the botamusique website URL with access token, types !connect to connect to LibreTime and starts to stream the show. At the end of the show, they type !disconnect to stop streaming. The stream automatically stops streaming to LibreTime if no one speaks for more than 30 seconds. This is to protect against streaming silence after a show if the DJ forgets to disconnect the stream before leaving.

 
Read more...

from taowa r.

Dino, packaged as dino-im in Debian, is an XMPP chat client. Thanks to the hard work of its developers, Dino has been making progress on supporting video and audio calls.

Building on the work of my co-maintainer, I've packaged the latest commits to dino-im in Debian experimental. Adapting to the changes in how Dino is built since the last release took a bit of effort, but I'm glad to say that experimental now has support for video calls in dino-im, and that they work quite well! I was able to test video calling for multiple hours, and while there were clearly still a few issues, the entire experience felt quite... comfortable. I'm confident that video calling will be in great shape for bookworm!

 
Read more...

from Deivite Cardoso

Eu costumo utilizar o Qemu/Kvm em todos os meus projetos de virtualização, muitas vezes necessito incrementar o meu disco.

Isso é bem simples utilizando o virsh que é o gerenciador principal. Com ele você pode pausar, criar, reiniciar e desligar domínios.

Todo o procedimento foi feito em uma VM chamada “debian10”.

Vamos lá!

1° Passo: Desligar a VM.

Antes de estender o volume é necessário primeiramente desligá-la.

$ sudo virsh shutdown debian10

Confirme se a VM está realmente desligada.

$ sudo virsh list

2º Passo: Localizar o caminho do Disco.

Localize o caminho do disco com o seguinte comando.

$ sudo virsh domblklist debian10

O meu disco está localizado em:

vda /var/lib/libvirt/images/debian10-1.qcow2

Caso você queira saber mais detalhes sobre o disco, como tamanho e formato, utilize o seguinte comando.

$ sudo qemu-img info /var/lib/libvirt/images/debian10-1.qcow2

3° Passo: Aumentando o Disco da VM.

Como já sabemos agora o caminho do nosso Disco Virtual, basta estendê-lo com os valores desejados.

sudo qemu-img resize /var/lib/libvirt/images/debian10-1.qcow2 +10G

OBS: Esse procedimento com o qemu-img só é possível sem Snapshot, sendo assim, caso o seu domínio possua algum Snapshot, é necessário removê-los e depois aumentar o Disco.

Liste os Snapshots com o seguinte comando.

sudo virsh snapshot-list

Remova o Snapshot: (Caso tenha mais de um snapashot, realize a remoção individualmente).

sudo virsh snapshot-delete --domain debian10 --snapshotname snapshot1

sudo virsh snapshot-delete --domain debian10 --snapshotname snapshot2

Agora, basta adicionar o espaço necessário.

sudo qemu-img resize /var/lib/libvirt/images/debian10-1.qcow2 +10G

Até breve!

 
Leia mais...

from paddatrapper

I have spent the last week getting Jitsi setup for streaming to RTMP endpoints. While the directions in the Jibri docs are fairly straight forward, I found it very difficult to troubleshoot when things went wrong.

Jitsi has multiple moving parts, and the streaming/recording section is no different. It is done through a separate app, Jibri, which launches a Chrome instance, controlled through Selenium, captures the output and streams/records it with FFmpeg.

If there are issues with the recorder authenticating against the Prosody XMPP server while Jibri is connecting to the call, it will timeout and the error

SEVERE: [117] org.jitsi.jibri.selenium.pageobjects.CallPage.visit() Timed out waiting for call page

and the prosody log will show an incoming connection, but no corresponding authentication success.

This issue is fixed by running the following on the Jitsi server:

prosodyctl register recorder recorder.domain.org $password

The other issue I encountered is that Jibri will start streaming and stop with

 timeout: no media received

if there are any NAT issues trying to negotiate the WebRTC connection. I found no other errors in the logs, only that it timed out after 30s. The 30s is defined in the Jibri code. I even saw the live stream correctly determine the number of people in the call and show their avatars, but it failed to show video, even when it was enabled. I fixed this by moving the Jibri service to run on the same server as Jitsi, with no NAT between it and the Internet.

One final note is that Jibri, Chrome and FFmpeg require a fair amount of memory and CPU. So small VPS setups with 1 vCPU and under 4GB of memory will fail to work, again with nothing in the logs. top is your friend in diagnosing this issue.

 
Read more...

from Leandro Ramos

Buster Backports

Uma das formas mais seguras de obter software mais recente no Debian Stable é através do repositório Backports, que contém pacotes que são portados do ramo Debian Testing para o Debian Stable.

Nem todo pacote do Debian Stable possui um backport. Para ver os backports disponíveis, você pode visitar a página de backports.

Ah, e os backports só existem para versões stable do Debian, pois Testing e Unstable estão sempre recebendo novas versões de pacotes.

Buster Backports

Habilitando os backports

Existem ferramentas gráficas para isso, mas fazendo pelo terminal eu posso mostrar de uma forma que funciona em qualquer ambiente desktop do Debian Stable. Adicione uma linha com o repositório buster-backports ao arquivo /etc/apt/sources.list:

sudo nano /etc/apt/sources.list

Adicione a linha seguinte:

deb http://deb.debian.org/debian/ buster-backports main

O arquivo ficará parecido com o da imagem abaixo:

sources.list

Atualize a lista de pacotes:

sudo apt update

Instalando pacotes a partir do buster-backports

Para instalar um pacote a partir do buster-backports, use o comando apt install como mostrado abaixo:

sudo apt install -t buster-backports libreoffice-writer

O comando acima vai atualizar o meu LibreOffice da versão 6.1.5 para a 6.4.4.

Se quiser atualizar todos (ou quase todos, pois alguns tem que ser mencionados explicitamente) os pacotes do sistema que tenham uma versão no buster-backports, use o comando:

sudo apt -t buster-backports upgrade

O sistema mostrará a lista de pacotes que serão atualizados. Caso não queira fazer assim, faça somente com os pacotes que desejar. Com o comando acima meu sistema atualizou muitos programas, incluindo o kernel, da versão 4.19 para a 5.5.

LibreOffice buster-backports

Até a próxima, pessoal!

 
Leia mais...

from paddatrapper

With the COVID-19 outbreak, may conferences have moved to be fully virtual. This has been achieved by streaming talks and using IRC or other channels for audience participation. Libreplanet used Jitsi to connect the moderators and presenters and IRC to facilitate discussion between attendees. The talks were streamed to their website, where people could watch them.

DebConf 19 also experimented with remote participation for two talks: What's new in the Linux kernel and Anti-Harassment Bof. These used RTMP and Jitsi respectively.

In both cases, I have observed several limitations that prevent the experience from feeling fully engaging and from flowing smoothly. Jitsi provided real-time communication, but this does not scale to include the audience. It lacks the moderation features required for a presenter to give a talk and take questions without allowing people, even accidentally, to take over the stream and the output video. RTMP provided this flexibility, but requires specific configuration to prevent the delay between presenter and attendee to be large enough that real-time Q&A is impossible. Further, as seen at Libreplanet and DC19, the Jitsi solutions ended up running through an RTMP CDN before reaching attendees anyway. This incurs additional delays.

Proposal

While these existing solutions can be shoe-horned into working, I would like to take the opportunity to develop a better solution, one that ideally integrates the strengths highlighted above, while mitigating some of the weaknesses. From my point of view, I see the following list of requirements:

  1. Configurable rooms – conference organisers need to be able to set up different rooms, similar to how a physical conference does. A room can have talks, BoFs or could be a 'hallway track' (where attendees can have discussions between themselves).
  2. A talk can have 1 or more presenters and some moderators. The presenter is responsible for displaying their own slides (OBS, screen sharing, etc), while the moderator is responsible for managing the room. This includes time remaining, questions and introducing the presenter.
  3. Attendees can join and watch anonymously, but are required to identify themselves in order to ask questions or participate in discussion. This reduces abuse and allows moderators to ensure that the conference Code of Conduct is adhered to.
  4. Discussion can occur in an embedded IRC client in the software. Thus existing IRC workflows are maintained and low-bandwidth remote participation is possible.
  5. Q&A can be handled through the web-interface. Attendees can signal that they have a question, and a moderator or the presenter can allow them to ask. This audio question is relayed to everyone in the room and once the question is asked, the audio is switched back to the presenter/moderator.
  6. Attendees can mute their audio and/or video without issue.

There are several opportunities for bad actors to abuse this system. Questions will need to be able to be cut short by moderators if necessary. In presentation talks, attendee audio needs to be muted unless explicit permission is given for the attendee to talk. Attendee registration for inclusion in the discussion is important, as this allows moderators to ban bad actors more easily.

In BoF sessions, the audio policy needs to be slightly different from presentation talks. In a BoF, many people give input and the discussion is more of a round-robin style. Here, people should be able to indicate that they intend to be part of the discussion, thus having their audio and video unmuted. The discussion then takes the style adopted by most chat clients, such as Jitsi, where the active speaker's video is shown. This should be able to be overridden by a constant video source such as slides or some other relevant information.

I envision this system would use RTMP on the backend, allowing people to connect to end-points mapped to rooms. This would allow people to use OBS or other streaming software to integrate slides, transitions and other media into their presentations. I would like to leverage existing software such as Jitsi and IRC if possible, as this would make implementation easier (hopefully). Development is on GitLab. If you are interesting in getting involved, or have comments: @paddatrapper@pleroma.debian.social

More concrete planning is happening here

 
Read more...

from paddatrapper

Discourse is a community discussion platform that is touted to replace email for project discussions. I am active on two instances for software projects I am involved with. I mainly interact with the web-interface, but I have been meaning to try the email interface for a while. The recent discussion in Debian about the future of mailing lists has finally pushed me to actually give it a try.

Discourse has categories and topics. A category can be thought of as a mailing list with topics as the individual threads.

I like the email support Discourse has, but I have found it lacking in two major respects:

  1. I am unable to create topics in a category via email. This is apparently possible, but I was unable to find a way of doing it in either of the two instances. Perhaps it requires additional configuration from the instance administrators for it to work.
  2. I am unable to reply to a topic via email if I have not been emailed about it by the system. The mailing list archive has the option to reply to an email by clicking on a link on the page. This composes an email with the Subject and To fields populated with the correct values. This is impossible in discourse, but it does allow you to reply through the web-interface. Future replies are then sent to me as emails, which I can reply to as normal.

Both of these issues have work-arounds, but they make email a second-class citizen on the discourse platform for now.

EDIT 12 March 2020: When configured correctly, new threads can be created by emailing the topic-name@instance.url (for example site-feedback@example.com)

 
Read more...

from highvoltage

The role of the Debian Project Leader doesn't really come with a lot of direct power and control over the project. A DPL has the power to delegate responsibility to others on behalf of the project, approve expenses, and some other administrative minutia. Because of the limited powers of the DPL, some have said that the DPL doesn't yield much influence of the project.

The reality is that the role of a DPL provides a commodity that is both very rare and very valuable these days: attention. When the Debian project leader speaks, it's not only the Debian community at large that listens, but everyone. Everyone from news sources, other distributions, business people and government decision makers pays attention to what Debian does and what it's leader says.

I can understand the desire for a project leader to say “I'm only speaking for myself here as an individual DD...”, but I believe that if you're willing to serve as DPL for a term, you should be able to put your own feelings on the side a bit and just represent the project fully as best as you can.

 
Read more...

from highvoltage

I'll admit it, I still like it when people say “You were right”, but I'm much more thankful for every time that I learned I was wrong, and every time I learned that I wasn't nearly as clever as I thought I was. Every one of these occurrences lead me to dig deeper and learn and grow, and without that I wouldn't be in a position to prove those wrong who told me “You'll never make it” and “You have too high hopes”, “The worlds is going to crush you”, etc.

When I was young, old people used to think that I had some very odd ideas and told me “You'll change your mind about this as you get older”. I'm glad that as I did get older, many of my thoughts that might have been considered rebellious or liberal have not only evolved and grown over time, but has increasingly been validated by the big thinkers of the world who care for and want to improve humanity.

Today was tough, but tomorrow will be better.

 
Read more...