News that might affect BunsenLabs

jeffreyC · 2021-05-07 07:00:12

o9000 wrote:

jeffreyC wrote:
pulseaudio which was inflicted upon us in a pre-alpha state.
Surely the community has learned the lesson and will not push pipewire prematurely, right? ... Right?!

It was invented by Red Hat employees.
They sell support.
It is in their economic interest for their product to break, so they release buggy code.
After all; who would pay for support on something that never fails?

hhh · 2021-05-07 11:52:16

o9000 wrote:

jeffreyC wrote:
pulseaudio which was inflicted upon us in a pre-alpha state.
Surely the community has learned the lesson and will not push pipewire prematurely, right? ... Right?!

We literally are just an Openbox/tint2/conky, LIVE USB, WiFi driver friendly config of Debian. When they adopt Pipewire, we adopt Pipewire (unless there's a better available setup, like if Pipewire turns out to be buggier than is acceptable and PulseAudio is still in the Debian repos, which it will be, we'll stay with Pulse for a bit longer).

DeepDayze · 2021-05-10 03:06:43

Pipewire now has crept into Debian...albeit disabled by default but down the road it may be the be-all replacement for Pulse. Hopefully it will truly be better and looking for the wiki and reviews on Pipewire before I am comfortable in setting it up.

Maybe a guide for setting PipeWire up on BL?

johnraff · 2021-05-10 04:50:17

Pulse had a bad start, but is it that awful now?

Anyway:

jeffreyC wrote:

o9000 wrote:
jeffreyC wrote:
pulseaudio which was inflicted upon us in a pre-alpha state.
Surely the community has learned the lesson and will not push pipewire prematurely, right? ... Right?!
It was invented by Red Hat employees.
They sell support.
It is in their economic interest for their product to break, so they release buggy code.
After all; who would pay for support on something that never fails?

Pipewire wrote:

It was created by Wim Taymans, Principal Engineer at Red Hat and co-creator of the GStreamer multimedia framework.

https://pipewire.org/#documentation

ohnonot · 2021-05-10 06:21:05

johnraff wrote:

Pulse had a bad start, but is it that awful now?

This.

jeffreyC · 2021-05-10 15:06:33

ohnonot wrote:

johnraff wrote:
Pulse had a bad start, but is it that awful now?
This.

So we should just give it about 15 years and it will be usable?

Naik · 2021-05-20 18:57:34

Hey there!

On a totally other topic: Bunsenlabs Linux should be correctly identified by
Lynis (Security Software) from version 3.0.5 on as of this closed issue.

Naik --greetz

Last edited by Naik (2021-05-20 19:04:34)

hhh · 2021-05-20 20:03:14

ohnonot wrote:

johnraff wrote:
Pulse had a bad start, but is it that awful now?
This.

I use PulseAudio on Bullseye with no issues, I mix my radio shows using it. I do use the equalizer sink (default flat settings), the speaker output sounds better to my ear...

https://forums.bunsenlabs.org/viewtopic.php?id=5700

I was just reporting some news that might affect BunsenLabs.

johnraff · 2021-07-23 00:58:26

Releasing bullseye on 14 August 2021

...we now have a release date for
bullseye: 14 August. For the avoidance of doubt, this is *not* a
tentative date anymore.

Debian-release mailing list:
https://lists.debian.org/debian-release … 00669.html

hhh · 2021-07-23 02:11:51

Right, let's go boys!

johnraff · 2021-07-23 02:20:18

Yup!

DeepDayze · 2021-07-23 15:51:28

johnraff wrote:

Releasing bullseye on 14 August 2021
...we now have a release date for
bullseye: 14 August. For the avoidance of doubt, this is *not* a
tentative date anymore.
Debian-release mailing list:
https://lists.debian.org/debian-release … 00669.html

So Beryllium is near. Go Team BL!

hhh · 2021-07-24 03:31:24

New sources have been added for bullseye, security updates and volatile updates...

deb https://deb.debian.org/debian bullseye main non-free contrib
# deb-src https://deb.debian.org/debian buster main non-free contrib

## Debian security updates
#deb https://deb.debian.org/debian-security buster/updates main contrib non-free
deb http://security.debian.org/debian-security bullseye-security main contrib non-free

# buster-updates, previously known as 'volatile'
#deb https://deb.debian.org/debian buster-updates main contrib non-free
#deb-src https://deb.debian.org/debian buster-updates main contrib non-free
deb http://deb.debian.org/debian bullseye-updates main contrib non-free

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

johnraff · 2021-12-19 07:30:51

Bullseye Debian Installer will allocate only 1GB of swap in "guided" mode.

https://bugs.debian.org/cgi-bin/bugrepo … bug=987503

So you need to set a bigger swap manually if you plan to use "Hibernate".

DeepDayze · 2021-12-19 20:50:51

johnraff wrote:

Bullseye Debian Installer will allocate only 1GB of swap in "guided" mode.
https://bugs.debian.org/cgi-bin/bugrepo … bug=987503
So you need to set a bigger swap manually if you plan to use "Hibernate".

I don't use Guided Mode generally anyway but for those who aren't that skilled there needs to be a better way to calculate how much swap to allocate especially on laptops as hibernation on desktops generally is pretty much broken.

johnraff · 2021-12-20 05:41:17

DeepDayze wrote:

hibernation on desktops generally is pretty much broken

It worked fine on my Lithium desktop out of the box, but there's no need for it really because there's no battery to drain if on a long suspend-to-ram. For that matter, a desktop in my bedroom is a lower security risk than a laptop out in public, so can just be left switched on if in the middle of some job.

So it's laptops that might want hibernation I think. The generally accepted wisdom seems to be that you want swap a bit bigger than your RAM. That's not always the end of the story though. (Some day I have to find out how to hibernate a system with an encrypted disk.)

trinidad · 2021-12-20 16:46:24

The generally accepted wisdom seems to be that you want swap a bit bigger than your RAM

This is dependent more on what's running when you begin hibernation. Disconnect the internet, shut down most applications, get all pending updates installed, and then 500MB is more than sufficient. Resuming RAM chips can be a random issue when loaded and working prior to hibernation so thus the assumption that swap needs to be bigger than RAM which is rarely true and more dependent on the preset hardware modes on the board itself. There really is no way to calculate a predictable size for swap during hibernation.

So it's laptops that might want hibernation I think

This is very true because laps under battery power are insecure in suspend mode even with encryption, as keys are written to swap in plain text. The portability of small devices introduces such vulnerabilities. Hibernation is more secure if a theft occurs.

Some day I have to find out how to hibernate a system with an encrypted disk

Definitely some unicorn chasing for this. The first problem is the random key generation for swap and the use of UUIDs in fstab. Even when overcome with the use of LVMs the resume can only obtain garbled data. I saw a solution once that involved UEFI and secure boot and code injection but to date there is no UI (like gparted) software for such an undertaking.

TC

DeepDayze · 2021-12-20 17:29:46

johnraff wrote:

DeepDayze wrote:
hibernation on desktops generally is pretty much broken
It worked fine on my Lithium desktop out of the box, but there's no need for it really because there's no battery to drain if on a long suspend-to-ram. For that matter, a desktop in my bedroom is a lower security risk than a laptop out in public, so can just be left switched on if in the middle of some job.
So it's laptops that might want hibernation I think. The generally accepted wisdom seems to be that you want swap a bit bigger than your RAM. That's not always the end of the story though. (Some day I have to find out how to hibernate a system with an encrypted disk.)

True, but not all desktops hibernate properly maybe due to BIOS bugs, but s2ram works if you want to let your desktop hold your work while you sleep...

Think you'd need encrypted swap for hibernating a system with full disk encryption.

johnraff · 2021-12-21 05:25:51

That swap is used for storing the content of RAM during hibernation is just a coincidence really. To set aside a dedicated partition for hibernating would be wasteful, so as far as I know all systems re-use swap for this. Presumably if there is data in swap at the time then it will be written back to disk first.

trinidad wrote:

The generally accepted wisdom seems to be that you want swap a bit bigger than your RAM
This is dependent more on what's running when you begin hibernation. Disconnect the internet, shut down most applications, get all pending updates installed, and then 500MB is more than sufficient...
There really is no way to calculate a predictable size for swap during hibernation.

Agreed, but you can calculate the maximum swap needed on a particular machine, ie the size of installed RAM. These days disk space is plentiful, so it's only a minority of users who'll need to decide exactly how much swap they're going to allocate. For the average new user who wants to be able to hibernate then a-bit-more-than-ram seems a reasonable choice. If you're going to shut down running apps then what are you planning to preserve by hibernating anyway? Why not just poweroff the machine?

Some day I have to find out how to hibernate a system with an encrypted disk
Definitely some unicorn chasing for this.

Some people claim to have solutions, and the more recent ones look simpler so things might have improved. I'll post a new thread if I get it working on my laptop.

DeepDayze wrote:

s2ram works if you want to let your desktop hold your work while you sleep...

Or just apply the screenlock and leave it booted up?

Think you'd need encrypted swap for hibernating a system with full disk encryption.

Do you mean swap encrypted separately from the rest of the disk?

My whole disk is encrypted under one LUKS password, except for /boot (unless I'm misunderstanding what the Debian Installer set up).
(I think a solution for including /boot in the encryption might not be far away.)

johnraff · 2022-01-08 09:27:56

Thunderbird no longer supports Movemail accounts

The recent Debian upgrade of Thunderbird to 91.4 has exposed us to the upstream devs' decision to drop support for Unix Movemail accounts:
https://bugzilla.mozilla.org/show_bug.cgi?id=1625741

I was enjoying being able to read root messages about hard disk health, upgrade issues etc when I checked my regular email, quite annoyed to lose my localhost TB account and spent a morning googling around, till I finally hit on a relatively easy fix using dovecot to serve the contents of /var/mail/john as imap. Dovecot's default configuration seems to be to do exactly that.

The lack of complex configuration might compensate for having to run another daemon - install dovecot-imapd + deps and configure a new imap account in TB to access it:
https://forums.linuxmint.com/viewtopic. … 0#p2089364

Problem sort of over, though I'm still keeping my eyes open for a tutorial on how to use the more lightweight mailutils-imap4d instead.

#181 2021-05-07 07:00:12

Re: News that might affect BunsenLabs

#182 2021-05-07 11:52:16

Re: News that might affect BunsenLabs

#183 2021-05-10 03:06:43

Re: News that might affect BunsenLabs

#184 2021-05-10 04:50:17

Re: News that might affect BunsenLabs

#185 2021-05-10 06:21:05

Re: News that might affect BunsenLabs

#186 2021-05-10 15:06:33

Re: News that might affect BunsenLabs

#187 2021-05-20 18:57:34

Re: News that might affect BunsenLabs

#188 2021-05-20 20:03:14

Re: News that might affect BunsenLabs

#189 2021-07-23 00:58:26

Re: News that might affect BunsenLabs

#190 2021-07-23 02:11:51

Re: News that might affect BunsenLabs

#191 2021-07-23 02:20:18

Re: News that might affect BunsenLabs

#192 2021-07-23 15:51:28

Re: News that might affect BunsenLabs

#193 2021-07-24 03:31:24

Re: News that might affect BunsenLabs

#194 2021-12-19 07:30:51

Re: News that might affect BunsenLabs

#195 2021-12-19 20:50:51

Re: News that might affect BunsenLabs

#196 2021-12-20 05:41:17

Re: News that might affect BunsenLabs

#197 2021-12-20 16:46:24

Re: News that might affect BunsenLabs

#198 2021-12-20 17:29:46

Re: News that might affect BunsenLabs

#199 2021-12-21 05:25:51

Re: News that might affect BunsenLabs

#200 2022-01-08 09:27:56

Re: News that might affect BunsenLabs

Board footer