Do you use any of our Fedora Labs? These are spins of Fedora that are set up with specific use cases in mind.

We have labs for:
* Astronomy
* Neuroscience
* Design
* Gaming
* Music
* And more!

➡️ fedoraproject.org/labs

#FedoraLabs #Fedora #Linux #OpenSource

Hello!
Who knows how do I pin a package to a specific version in #archlinux? Something like apt's package pinning in Debian.

Why? I don't want to update my kernel to newest versions where the team just silently removed more than 10 Russian developers from maintainers list. This is not fair and I will stay on honest versions with honest maintainers list.

#linux #foss

Die #ubuntu 24 Neu #Installation scheint vor Veröffentlichung nicht einmal ohne Verwendung der Maus getestet worden zu sein...

#a11y #Accessibility #Linux

Being Penguin

#unix_surrealism #comic #technomage #linux #openbsd #foss

Oops, it happened again! @cas flashed @postmarketOS onto my old Pixel 3 this time. This is becoming a pattern! 😝

#GNOME #PostmarketOS #Linux #LinuxMobile #Berlin

This is how I feel when I ssh using my mobile phone.

#ssh #linux #unix #android #ios

Der Windows 10 Support nähert sich dem Ende. Zeit für den Umstieg auf Windows 11 oder doch der perfekte Moment, um der Abhängigkeit von Microsoft zu entkommen? Es gibt viele Alternativen – Linux, Open-Source-Tools, Datenschutz und Freiheit warten. Was denkst du: Upgrade oder Ausstieg?

#Windows10 #Windows11 #Linux #OpenSource #Datenschutz

>> Na windows má člověk antivirus a na linuxu má člověk rozum ;)

#MoudroDne o #Linux

We're coming to the last few talks for the conference, but the excitement continues...

Now Mathias Clasen is going through the state of #HDR in #GTK4

#linux #multimedia #gnome #video #gstconf2024

User Group idea: cURL girls. a group for women dedicated to hacking the internet via the command line.

the name popped in my head, and thought it should exist. Someone should run with it.

#linux #curl #CLI #NameIdea

Also, happy 25th birthday to us! 🎊🎉🎊🎉

#linux #multimedia #gstreamer #gstconf2024

🤍 Appeal to the Browser Goddesses 🤍

Can we please make it a thing where 32GB of RAM isn't an insufficient amount for day to day web browser usage? Getting an OOM core dump for that reason is inexcusable.

- Should the Zoom browser app really need 2GB on a single tab when it's already downscaling a 1080p feed to 320p on an enterprise account?
- Should Amazon's website really need 1GB per tab just to view the cart or a ~800Mb for a single simple product page?
- Please remind me how an MKdocs fully static page with a single 400k image and no datatables or fancy JS somehow require 242Mb?
- Or perhaps shed some light on the requirement where Google's main page with a single search form somehow needs ~500Mb

There are no "good reasons" for these inefficiencies. We don't suddenly have better search fields or compressed jpegs now vs a decade ago with 1/10th of the system resources.

#developer #webdev #linux #browsers #chrome #firefox #ensh11n

What OS are you using on a daily basis?

#Windows #macos #Linux #Android #iOS #Chromeos #Computer #mobile #Vivaldi

• Windows (36%, 2436 votes)
• MacOS (34%, 2273 votes)
• Linux (56%, 3790 votes)
• ChromeOS (1%, 127 votes)
• Android (40%, 2726 votes)
• iOS (29%, 1964 votes)
• Other (2%, 182 votes)

Future of salt in our repositories

lists.archlinux.org/archives/l…

#salt #saltstack #ArchLinux #Linux

this is, like a lot of my posts where I'm not replying to threads, concerning #blind users of #linux. With that out of the way, let's get into it

So, I was technically able to do this for some time now, around three days or so, but now I got enough courage to actually do it. This involves a lot of courage indeed, because this is my primary and only system, and the experiment in question could have cost me speech on the computer, which is a pretty big deal

So yeah, what did I do that's so dangerous? I stopped the pulseaudio server, entirely, and by that I mean the pulse pipewire compatibility layer, pipewire-pulse. Foolishly as it might sound from the outside, I tryed this to see if I could still get speech. Not so foolishly after all, and also in a show of spectacularly defying expectations, because I'm writing this now, I do, very much so, in fact, as an unintended consequence, my system feels snappier too, incredible, right?

As many of you are pretty technical, since using linux as a VI person kinda pushes you in that direction, it should not come as any surprise to you that speech dispatcher uses pulseaudio, aka pipewire-pulse, to play sound, because usually when that crashes, you get no speech and such. So then, how is this possible? no, I'm not using alsa, or any of the other audio backends in there. The rest of this huge post will be devoted to that question, as well as explaining some background around why this matters and how things were before. Note: this would probably only make a lot of positive change to a particular group of people, those who value the amount of latency of your audio systems, either because you're musicians, want to be, are working with specialised audio software, are using a complicated hardware setup with lots of nodes which have to be balanced in the right way, or just because you can, etc etc, those kinds of people. For most of you, this may be a novelty, may get some limited use out of it due to decreased cpu load and more fast feeling interfaces in your desktop environments, but for you, this is mostly a nice read and some hipped enthusiasm I suppose.

It all started when I was talking to afew linux musicians, if I recall correctly, also someone who might have been involved in a DAW's development. I was talking about accessibility, and finally arrived to someone telling me that speech dispatcher requests a very low latency, but then xruns quite a number of times, making pipewire try to compensate a lot. I could be misremembering, but they also said that it throws off latency measuring software, perhaps those inside their DAW as well, because the way speech dispatcher does things is making pw increase the graph latency.

So then, what followed were afew preliminary discussions in the gnome accessibility matrix room, about how audio backends work in spd. There, I found out that plugins mostly use a push model, meaning they push samples to the audio server when those become available, in variable sizes as well, after which the server can do the proper arrangements for some kind of sane playback of those. Incidentally or not, this is how a lot of apps work with regular pulseaudio, usually using, directly or indirectly, a library called libpulse_simple, which allows one to basically treat the audio device like some kind of file and have things done that way, where the library could also sometimes introduce buffering of its own before sending to pulse, etc. Of note here is that pulse still has callbacks, but a lot of apps don't use that way of doing things.

Back to the problem though, this was fine for pulse, more or less anyway, because pulse didn't symbolise the media graph in any way, there was simply no such concept there, you had only apps being connected to devices via streams, so there wasn't a way with which to get apps to syncronise their rates to something which can more or less be sent directly to the soundcard. So, when apps invariably started to diverge the rate at which they pushed samples to pulse, as far as I understand, pulse took the latency of the slowest stream and add it to everyone else to attempt to syncronise, because, after all, pulse would still have to mix and send everyone's frames to the soundcard, and because there either was no poling model or no one wanted to implement it, that was the best choice to make in such environments.

Enter low-latency software, #jack and #pipewire. Here, latency minimising is the most important thing, so samples have to be sent to the soundcard as soon as possible. This means that the strategy I outlined above wouldn't work here, which gets us neetly in the concept of an audio graph, which is basically all the sound sources that can play, or capture, in your systems, as well as exactly where sound is played to and captured from. Because of the low-latency factor however, this graph has to be poled all at once, and return samples similarly fast, in what the graph driver calls a cycle. The amount for which apps can buffer audio before they're called again, aka a graph cycle duration, is user-adjustable, in jack via the buffer size, in pipewire via the quantum setting. But then, what happens to apps which don't manage to answer as fast as they get called by the server? Simple, even simpler than the answer of pulse, alsa, etc to the problem, and their various heuristics to try to make sound smooth and insert silence in the right places. The answer is, absolutely nothing at all, if an app didn't finish returning its alotted buffer of samples, not one more or less than that, the app would be considered xrunning, either underrunning or overrunning based on the size of the samples buffer they managed to fill, and their audio, cutting abruptly with perhaps afew bits of uninitialised memory in the mix, is sent to the soundcard at a fixed time, with the others. This is why you might be hearing spd crackle weirdly in vms, that's why you hear sometimes other normal programs crackle for no good reason whatsoever. And you know, this is additive, because the crackling spreads through the entire graph, those samples play with distortion on the same soundcard with everything else, and everyone else's samples get kinda corrupted by that too. But obviously, if it can get worse, it will, unfortunately, for those who didn't just down arrow past this post. There are afew mechanisms of reducing the perceived crackling issues from apps which xrun a lot, for example apps with very low sample rates, like 16 khz, yes, phone call quality in 2024(speaking of speech dispatcher), can get resampled internally by the server, which may improve latency at the cost of a degraded quality you're gonna get anyways with such a sample rate, but also te cpu has to work more and the whole graph may again be delayed a bit, or if an app xruns a lot, it can either be disconnected forcefully by pipewire, or alternatively the graph cycle time is raised at runtime, by the user or a session manager acting on behalf of the user, to attempt to compensate, though it'll never go like regular pulse, but enough to throw off latency measuring and audio calibration software.

So, back to speech dispatcher. After hearing this stuff, as well as piecing together the above explanation from various sources, I talked with the main speech dispatcher maintainer in the gnome a11y room, and came to the conclusion that 1, the xrunning thing is either a pipewire issue or a bug in spd audio plugins which should be fixed, but more importantly B, that I must try to make a pipewire audio backend for spd, because pw is a very low-latency sound server, but also because it's the newest one and so on.

After about two weeks of churn and fighting memory corruption issues, because C is really that unsafe and I do appreciate rust more, and also I hate autotools with passion, now my pr is basically on the happy path, in a state where I could write a message with it as it is now. Even on my ancient system, I can feel the snappyness, this really does make a difference, all be it a small one, so can't wait till this will get to people.

If you will get a package update for speech dispatcher, and if you're on arch you will end up doing so sooner or later, make sure you check the changes, release notes, however your package repositories call that. If you get something saying that pipewire support was added, I would appreciate it if as many of you as possible would test it out, especially when low-latency audio stuff is required, see if the crackling you misteriously experienced from time to time with the pulse implementation goes away with this one. If there are issues, feel free to either open them against speech dispatcher, mention them here or in any other matrix rooms where both me and you are, dm me on matrix or here, etc. For the many adventurers around here, I recommend you test it early, by manually compiling the pull request, I think it's the last one, the one marked as draft, set audio output method to pipewire in speechd.conf, replace your system default with the one you just built by running make install if you feel even more adventurous , and have fun!

I tested this with orca, as well as other speech dispatcher using applications, for example kodi and retroarch, everything works well in my experience. If you're the debugging sort of person, and upon running your newly built speechd with PIPEWIRE_DEBUG=3, you get some client missed 1 wakeups errors, the pipewire devs tell me that's because of kernel settings, especially scheduler related ones, so if y'all want those to go away, you need to install a kernel configured for low-latency audio, for example licorix or however that is spelled, but there are others as well. I would suggest you ignore those and go about your day, especially since you don't see this unless you amp up the debugging of pipewire a lot, and even then it might still just be buggy drivers with my very old hardware.

In closing, I'd like to thank everyone in the gnome accessibility room, but in particular the spd maintainer, he helped me a lot when trying to debug issues related to what I understood from how spd works with its audio backends, what the fine print of the implicit contracts are, etc. Also, C is incredibly hard, especially at that scale, and I could say with confidence that this is the biggest piece of C code I ever wrote, and would definitely not want to repeat the experience for a while, none of the issues I encountered during these roughly two weeks of development and trubbleshooting would have happened in rust, or even go, or yeah, you get the idea, and I would definitely have written the thing in rust if I knew enough autotools to hack it together, but even so I knew that would have been much harder to merge, so I didn't even think of it. To that end though, lots of thanks to the main pipewire developer, he helped me when gdb and other software got me nowhere near solving those segfaults, or trubbleshooting barely intelligible speech with lots of sound corruption and other artefacts due to reading invalid memory, etc.

All in all, this has been a valuable experience for me, it has also been a wonderful time trying to contribute to one of the pillers of accessibility in the linux desktop, to what's usually considered a core component. To this day, I still have to internalise the fact that I did it in the end, that it's actually happening for real, but as far as I'm concerned, we have realtime speech on linux now, something I don't think nvda with wasapi is even close to approaching but that's my opinion I dk how to back up with any benchmarks, but if you know ways, I'm open to your ideas, or better, actual benchmark results between the pulse and pipewire backend would be even nicer, but I got no idea how to even begin with that.

Either way, I hope everyone, here or otherwise, has an awesome time testing this stuff out, because through all the pain of rangling C, or my skill issues, into shape, I certainly had a lot of fun and thrills developing it, and now I'm passing it on to you, and may those bugs be squished flat!

Speech Note - An Offline Speech Recognition, Text-to-Speech and Translation App for #Linux

ostechnix.com/speech-note-spee…

Well y'all, I broke something. I was using Emacs, and was committing a change to a repo like always, when my audio started to studder a bit. I'd noticed that Emacspeak sounds were a big sluggish, but I thought that was Sox being sox or Pipewire messing with something as usual. So I unplugged my Dell docking station, plugged it in again, and things returned to normal until the next time I committed. This time, audio stopped, and, well, never came back. I plugged the dock into my iPhone, and it worked. Windows, worked. Linux though? Nope. Not sure what's going on, but goodness I'm tired of technology. So tired of everything changing and breaking. Google Drive changed, so I'm having to redo the whole course on Google Docs/Drive. And this was not something I was expecting and definitely not something I needed today. So I'm gonna have to look for a way to reset the dock or something.

#linux #foss #accessibility #blind

Recommendations from your own personal experience, please!

I have a lot of DRM-free ePubs for which there is no audiobook.

I'd like to convert one or two of them into audiobooks.

I use Linux.

I don't have any high end machines, but I am happy to wait for a conversion process.

I want all conversion to be done locally, using FOSS.

I am content with a generic voice, else I could provide voice samples.

Have you done this and, if so, would you recommend what you did?

#Linux #audiobook #tts

📢 The GStreamer Conference 2024 schedule is now up!

gstreamer.freedesktop.org/conf…

See you next week in Montréal!

PS: don't forget to register

#gstreamer #linux #multimedia

I am pleased to announce a new Cambalache stable release, version 0.92.0!

What's new:
- Basic port to Adwaita
- Use Casilda compositor for workspace
- Update widget catalogs to SDK 47
- Improved Drag&Drop support
- Improve workspace performance
- Enable workspace animations
- Support new desktop dark style
- Support 3rd party libraries
- Streamline headerbar
- Lots of bug fixes and minor improvements

Read more about it at blogs.gnome.org/xjuan/2024/09/…

#GTK #LINUX #UI
@GTK @gnome

This was posted on a Google Pixel 3A (sargo) running postmarketOS with Phosh.

If I didn't choose to keep this device alive and useful with postmarketOS, it would have most likely ended up in a drawer somewhere, and then eventually a landfill somewhere.

As postmarketos.org states: "Let's keep our devices useful and safe untill they physically break!"

#PostMarketOS #MobileLinux #Linux

fyi to linux users, the unofficial signal desktop flatpak doesnt use the freedesktop Secrets API no matter what you do and leaves your keys completely unencrypted

you can just dump ~/.var/apps/org.signal.Signal and read everything stored

if you're concerned, you should probably use the native package

#linux #flatpak #signal #Security

In der Anwendung von freier, offener und wirtschaftlich fair betriebener Software sehen die Lukis eine praktische Verbindung zur #Freiheit des Evangeliums und vieler Narrative biblischer Texte.

Das war auch an diesem @luki@kirche.social Wochenende im Theologischen Seminar Herborn wieder zu spüren.

Ganz praktisch ging es z.B. um #GNUTaler, /e/OS, digitales in Kirchengemeinden, #Grist, #Matrix und Bots, #DeltaChat, #ElementX und die Server-Admin bei @hostsharing@geno.social

Die Location war ünrigens einzigartig

#FediKirche #digtialeKirche #selbstbestimmtDigital#Linux #FOSS #OpenSource

From a Mailing List:

As some of you may already know, System76 is working on their new Linux graphical interface, the COSMIC desktop. They have created a form with some questions related to accessibility. If anyone is interested in participating in the survey, please access the address below:

docs.google.com/forms/d/e/1FAI…

#accessibility #Linux #foss #orca #blind

🪞 Introducing Mirror Hall, an app to turn any Linux devices into a second wireless monitor!

We use semi-custom P2P screen sharing optimized for low latency. Only Mutter-based DEs are currently supported as *senders*, whereas all DEs work as receivers.

This is our first unstable release, sp please be kind and report issues. If you are an #ARM user, we would love your help testing the gstreamer pipeline on new phones!

notes.nokun.eu/post/2024-09-22…

#linux #opensource #foss #gnome #apps #gstreamer

My colleagues @gpiccoli and André Almeida will attend the Linux Kernel Recipes 2024 in Paris, between the 23rd and the 25th of September. Make sure to talk to him if you are interested in what Igalia works on that is related to the Linux kernel and general OS development.

#igalia #kernelrecipes #linux #kernel