Re: [arch-general] Doubts with 'apulse'
Why do you need apulse to get firefox using alsa as backend? Perhaps you can take a look at [3] -- Javier [3] https://wiki.archlinux.org/index.php/Firefox/Tweaks#Get_ALSA_working_back signature.asc Description: OpenPGP digital signature
[arch-general] Doubts with 'apulse'
Hi, if this queries must go to some other specific places (forums,
AUR, etc.) please let me know so I move them there.
1. According to the instructions in [1] «it is necessary to exclude
/dev/snd/ from Firefox' sandboxing by adding it to the comma-separated
list in about:config → security.sandbox.content.write_path_whitelist»,
but right now I'm using '$ apulse firefox' without that exclusion and
seems to work fine. Maybe that's outdated? (My system is updated.)
2. According to [2] «to allow ALSA programs to play while JACK is
running edit (or create) /etc/asound.conf» with this:
# convert alsa API over jack API
# use it with
# % aplay foo.wav
# use this as default
pcm.!default {
type plug
slave.pcm "jack"
hint.description "Jack Audio"
}
Now, when I installed apulse, I got this instruction: «For using
PulseAudio emulation create a proper .asoundrc: $ cp
/usr/share/apulse/asoundrc.sample ~/.asoundrc».
Is there any relation or conflict between those two files?
BTW, I simply forgot to follow that apulse indication, but it seems to
work fine anyway. Maybe it's not necessary?
Thanks a lot.
[1] https://wiki.archlinux.org/index.php/Firefox#Multimedia_playback
[2]
https://wiki.archlinux.org/index.php/JACK_Audio_Connection_Kit#Playing_nice_with_ALSA
Re: [arch-general] Time stamps are in 24 hour format how can you change this.
That may be adjustable in orca settings if thunderbird respects orca settings. I think it's general and then date format and time format. On Mon, 6 Apr 2020, Matthew dyer via arch-general wrote: > Date: Mon, 6 Apr 2020 13:57:46 > From: Matthew dyer via arch-general > To: 'General Discussion about Arch Linux' > Cc: ilovecountrymusic...@gmail.com > Subject: [arch-general] Time stamps are in 24 hour format how can you change > this. > > Hi all, > > I am using Jenux which is a basic installer for arch Linux, but any I have > notest that for some reason when using thunderbird with orca, Time and day > are spoken in 24 hour format with year, month day followed by the time in 24 > hour format. My time zone is set correctly. For example 2020/2020/jfirstjf > 15:jj. Any one know how to switch to udds format? It's driving me crazy. > If I use orca to get the time it is spoken correctly. Thanks all. > > > > Matthew > > > > PS, I have checked the arch wiki, but came up empty. Thanks. > > > > > --
[arch-general] Time stamps are in 24 hour format how can you change this.
Hi all, I am using Jenux which is a basic installer for arch Linux, but any I have notest that for some reason when using thunderbird with orca, Time and day are spoken in 24 hour format with year, month day followed by the time in 24 hour format. My time zone is set correctly. For example 2020/2020/jfirstjf 15:jj. Any one know how to switch to udds format? It's driving me crazy. If I use orca to get the time it is spoken correctly. Thanks all. Matthew PS, I have checked the arch wiki, but came up empty. Thanks.
Re: [arch-general] Hibernation Failure
Am 12.01.20 um 12:19 schrieb Markus Schaaf via arch-general: > > > Am 12.01.20 um 01:39 schrieb Paul Dann via arch-general: >> I'm having trouble getting hibernation to work on my new Dell Inspiron >> 7590. It seems that the image is stored correctly (onto LUKS+LVM thin-lv), > > I've noticed something similar on a similar setup. It looks like the > kernel is taking some shortcuts when accessing the (swap-) space during > hibernation, which are not compatible with dm-crypt. I'm using an AEAD > cipher and the integrity data is wrong after resume. I know it is terribly late, but for those curious: While investigating this I managed to make my laptop unbootable, because dm-crypt decided that every single sector on my encrypted partition had a bad AEAD tag and wouldn't let me read a single byte. That was exactly what had been happening to my swap-partition before, when I tried to resume from hibernation. But this time it had eaten my root-partition too. Of course I had backups, encrypted (of course), with a key I had changed recently ... that I knew I needed to save somewhere else, but somehow forgot to. I'm writing this on exactly that laptop, restored completely from the "unreadable" SSD. But it took me some time to read the relevant kernel code, develop and run some helpful tools to search and decrypt the data on said partition. What I have found: It is unlikely that hibernation is the cause to the problem I have encountered. It is just the trigger. Somehow dm-integrity or dm-crypt manages to fuck up it's on-disk meta-data. (Meanwhile the same happened to my work desktop, which had a similar setup, after suspend to RAM.) After I had determined the exact encryption algorithm and layout of my data, I was able to not only read all of it, but the on-disk integrity-tags matched 100%. Every single sector. BR
Re: [arch-general] Multi-threaded mkinitpcio
On 06-04-2020 12:43, Ralph Corderoy wrote: Hi Lone Wolf, $ perf stat -e instructions gzip /dev/null $ perf stat -e instructions lzop /dev/null Those outputs appear to be from unpacking initramfs. I do think OP and Giancarlo were talking about creating an initramfs . Oh, sorry for the noise if I'm wrong, but /boot/initramfs-linux-lts-fallback.img is gzip-compressed here. I uncompressed it to give the initramfs-linux-lts-fallback used above. I thought the compression of it was the step OP and Giancarlo were discussing, as you say. Guess I misinterpretated the command, ralph . Below are some data from my own system (threadripper 1920x , NvME2 ssd) . lzop is about twice as fast as gzip , while xz is very slow. Lone_Wolf $ perf stat -e instructions mkinitcpio --generate testing --compress gzip > /dev/null Performance counter stats for 'mkinitcpio --generate testing --compress gzip': 16,585,047,999 instructions:u 4.706074377 seconds time elapsed 4.000137000 seconds user 1.18722 seconds sys $ perf stat -e instructions mkinitcpio --generate testing --compress xz > /dev/null Performance counter stats for 'mkinitcpio --generate testing --compress xz': 84,360,010,752 instructions:u 17.415348248 seconds time elapsed 16.75674 seconds user 1.500338000 seconds sys $ perf stat -e instructions mkinitcpio --generate testing --compress lzop > /dev/null Performance counter stats for 'mkinitcpio --generate testing --compress lzop': 5,316,618,410 instructions:u 2.426944720 seconds time elapsed 1.695263000 seconds user 1.027651000 seconds sys $
Re: [arch-general] Multi-threaded mkinitpcio
Hi Lone Wolf, > > $ perf stat -e instructions gzip > >/dev/null > > $ perf stat -e instructions lzop > >/dev/null > > Those outputs appear to be from unpacking initramfs. > I do think OP and Giancarlo were talking about creating an initramfs . Oh, sorry for the noise if I'm wrong, but /boot/initramfs-linux-lts-fallback.img is gzip-compressed here. I uncompressed it to give the initramfs-linux-lts-fallback used above. I thought the compression of it was the step OP and Giancarlo were discussing, as you say. -- Cheers, Ralph.
Re: [arch-general] Multi-threaded mkinitpcio
On 06-04-2020 11:47, Ralph Corderoy wrote: Hi Giancarlo, Of course lzop will be faster than xz, but mkinitcpio's default is gz, which should be comparable, at least in speed, with lzop. A slap-dash test. $ perf stat -e instructions gzip /dev/null Performance counter stats for 'gzip': 19,533,249,541 instructions:u 19.642066695 seconds time elapsed 19.540737000 seconds user 0.13000 seconds sys $ perf stat -e instructions lzop /dev/null Performance counter stats for 'lzop': 1,233,520,108 instructions:u 1.129177816 seconds time elapsed 1.092271000 seconds user 0.036743000 seconds sys $ gzip is about twenty times slower. 1,233,520,108 / 19,533,249,541 = 0.0631497644777874596 1.129177816 / 19.642066695 = 0.05748772944994829119 Yes, my computer is probably slower than most, but then perhaps so is the OP's. Those outputs appear to be from unpacking initramfs. I do think OP and Giancarlo were talking about creating an initramfs . LW
Re: [arch-general] Multi-threaded mkinitpcio
Hi Giancarlo, > Of course lzop will be faster than xz, but mkinitcpio's default is gz, > which should be comparable, at least in speed, with lzop. A slap-dash test. $ perf stat -e instructions gzip /dev/null Performance counter stats for 'gzip': 19,533,249,541 instructions:u 19.642066695 seconds time elapsed 19.540737000 seconds user 0.13000 seconds sys $ perf stat -e instructions lzop /dev/null Performance counter stats for 'lzop': 1,233,520,108 instructions:u 1.129177816 seconds time elapsed 1.092271000 seconds user 0.036743000 seconds sys $ gzip is about twenty times slower. 1,233,520,108 / 19,533,249,541 = 0.0631497644777874596 1.129177816 / 19.642066695 = 0.05748772944994829119 Yes, my computer is probably slower than most, but then perhaps so is the OP's. -- Cheers, Ralph.
Re: [arch-general] Multi-threaded mkinitpcio
thank you for these details. regard, lacsaP. Le lun. 6 avr. 2020 à 05:39, Giancarlo Razzolini via arch-general < arch-general@archlinux.org> a écrit : > Em abril 4, 2020 12:13 Jelle van der Waa escreveu: > > > > multi-threaded compression does not create a predictable reproducible > > archive (for xz/zstd). > > > > Zstd is multi-thread safe, as far as I know, xz is not. But the kernel does > not support zstd. > > > > > Sure, has nothing to do with reproducibility however. > > > > It has, because lzop is the only algorithm that produces unreproducible > builds > due to them adding their own timestamp, which there's no flag to remove. > Of course > lzop will be faster than xz, but mkinitcpio's default is gz, which should > be comparable, > at least in speed, with lzop. > > Regards, > Giancarlo Razzolini
