What the hell starts pulseaudio?!

Roderick hruodr at gmail.com
Thu Jul 15 10:11:16 UTC 2021

In my opinion it is clear that the problem is firefox. Trying to
solve it tricking the system is the false way.

The main problem is, that most web sites are de facto written for chrome,
and perhaps firefox. We need a browser, but are not free to select a
browser. Although there is a standard, we have something like a monople.

I ask me how difficult could be to write something lightweight, but
fully compatible with chrome and mantain it compatible. The similar
question with firefox. Perhaps something scriptable. It seems that
most of the browser is the render engine.

But we have the same problem with a much simpler technic: email.
The only lightweight mail client I know that is usable for
actual demand is: alpine. It is developed and mantained by only
one person.

I have the impression that free software movement has one side
very demanding goals, on the other side is neglecting very
elementary things.


On Thu, 15 Jul 2021, Ralf Mardorf wrote:

> On Thu, 15 Jul 2021 06:31:16 +0100, Steve O'Hara-Smith wrote:
>> you'll almost certainly have to build it from source
> This could take hours, at least on Linux with an Intel Celeron dual-core
> CPU G1840 @ 2.80GHz, with 8 GiB RAM, so a regular tmpfs is too small to
> build Firefox and it needed to get build on a SATA3 SSD. Let alone
> building the Electron framework, based on Chromium, IIRC it took 1/4
> day. There's no reason that it can be expected to compiled faster on
> FreeBSD, just a computer with more horsepower can workaround this issue.
> Building those bloated browsers takes way longer then building kernels
> and due to security related updates you have to build browsers very
> often.
> On Linux pulseaudio became a default annoyance earlier than on FreeBSD
> and in the beginning there where absolutely no working ways just to
> disable an installed pulseaudio.
> If you just delete the pulseaudio related files, nothing that was
> compiled against it breaks, resp. audio might break, if no alternative
> sound architecture or a workaround is provided, but even then Firefox
> works without audio.
> On Linux an alternative apulse worked and it might still work, I don't
> know, since the packages of the Linux distro I'm using provide Firefox
> build against jack and ALSA, too.
> I still prefer to build empty dummy packages on Linux to fulfil
> dependencies of packages that were build against pulseaudio, instead of
> installing and disabling pulseaudio.
> Assuming "autospawn = no" is a solution that works without issues
> nowadays, the problem would be solved without a dirty hack. However,
> I'm in favour of the dirty hack, since it works without fail, even if a
> drop-in file or something else that gets introduced the other day, will
> break a solution that works today.
> If you rely on using Linux software on your FreeBSD install, than I've
> got bad news for you. If you prefer to stay with a reliable old-school
> environment, you are forced to get used to dirty hacks or to fork
> software, since it's even not granted that annoying things can be
> disabled or replaced by something else via config flags at build time.
> My all-day workstation is a _rolling release_ Linux distro, that
> follows upstream as close and fast as possible.
> Installed
> local/apulse 0.1.13-1
>    PulseAudio emulation for ALSA
> multilib/lib32-libpulse 14.2-2
>    A featureful, general-purpose sound server (32-bit client libraries)
> extra/pulseaudio 2013.08.18-1
>    Dummy package
> extra/pulseaudio-alsa 1:1.2.5-2
>    ALSA Configuration for PulseAudio
> extra/pulseaudio-bluetooth 2017.12.19-1
>    Dummy package
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"

More information about the freebsd-questions mailing list