On Du, 27 iun 21, 11:50:59, Celejar wrote:
> On Sat, 26 Jun 2021 16:51:21 +0300
> Andrei POPESCU wrote:
>
> ...
>
> > Well, apparently lots of people[1] seem very upset about and hell bent
> > to change Signal's (the service) policies on federation, third-party
> > clients, etc.
> >
> > Why?
On 2021-06-28, Long Wind wrote:
>
>
> Thank IL Ka and Cater!i've run console-setup,
> but it's not persistent, after reboot, it uses ugly font again
> PS: i reply a little late, because yahoo is partially blocked
>
Looks like this four-year-old bug:
https://bugs.debian.org/cgi-bin/bugreport.c
On Mon 28 Jun 2021 at 11:20:12 -, Curt wrote:
> On 2021-06-28, Long Wind wrote:
> >
> >
> > Thank IL Ka and Cater!i've run console-setup,
> > but it's not persistent, after reboot, it uses ugly font again
> > PS: i reply a little late, because yahoo is partially blocked
> >
>
> Looks like
On 2021-06-28, Brian wrote:
> On Mon 28 Jun 2021 at 11:20:12 -, Curt wrote:
>
>> On 2021-06-28, Long Wind wrote:
>> >
>> >
>> > Thank IL Ka and Cater!i've run console-setup,
>> > but it's not persistent, after reboot, it uses ugly font again
>> > PS: i reply a little late, because yahoo is
Hi,
I have difficulties setting up Dovecot to connect to remote MariaDB
instance over TLS.
So I have two Debian 11 LXD containers spun up, one as mail server with
Postfix and Dovecot, and one as database instance with MariaDB. The LXD
host is Ubuntu 20.04.
I defined `passdb` in /etc/doveco
On Monday 28 June 2021 08:19:37 Curt wrote:
> On 2021-06-28, Brian wrote:
> > On Mon 28 Jun 2021 at 11:20:12 -, Curt wrote:
> >> On 2021-06-28, Long Wind wrote:
> >> > Thank IL Ka and Cater!i've run console-setup,
> >> > but it's not persistent, after reboot, it uses ugly font again
> >> > P
Bagas Sanjaya wrote:
> Hi,
>
> I have difficulties setting up Dovecot to connect to remote MariaDB instance
> over TLS.
>
> So I have two Debian 11 LXD containers spun up, one as mail server with
> Postfix and Dovecot, and one as database instance with MariaDB. The LXD host
> is Ubuntu 20.04.
T
On Sun 27 Jun 2021 at 05:31:05 (+0100), Gareth Evans wrote:
> On Tue 22 Jun 2021, at 19:13, David Wright wrote:
> > On Tue 22 Jun 2021 at 08:59:13 (+0100), Gareth Evans wrote:
> > > A recent dist-upgrade on Buster (in a scripted cron job run at 01:00
> > > daily) failed due to apt-listbugs compla
Hi all,
I've got about 5 years old HP laptop with SSD SATA drive 240 GB. Debian
Bullseye will be installed on it once it's released, as my secondary
computer to use.
I have question regarding whole disk encryption. What technology should
I use, to have encryption of everything, or at least /home,
On 2021-06-28, Gene Heskett wrote:
>>
>> The workaround at the bottom of the thread is to create a service file
>> that systematically deletes the cache at shutdown.
>
> That sucks unless its a gracefull shutdown, power failures don't leave
> time to do that, so why not clean the cache early in t
On Monday 28 June 2021 11:46:00 Curt wrote:
> On 2021-06-28, Gene Heskett wrote:
> >> The workaround at the bottom of the thread is to create a service
> >> file that systematically deletes the cache at shutdown.
> >
> > That sucks unless its a gracefull shutdown, power failures don't
> > leave t
Hello!
Currently testing the new Bullseye release (using
firmware-bullseye-DI-rc2-amd64-netinst.iso) and see a strange phenomenon on
a HP Proliant DL380 G7 server.
During boot, the following messages show up in the console:
[63.063844] pcc_cpufreq_init: Too many CPUs, dynamic performance scaling
piorunz:
>
> I have question regarding whole disk encryption. What technology should
> I use, to have encryption of everything, or at least /home, but preserve
> free blocks and have TRIM?
The canonical answer is "LUKS". You can configure it during installation
if you want to. I always use LVM as
On 6/28/21 7:52 AM, piorunz wrote:
Hi all,
I've got about 5 years old HP laptop with SSD SATA drive 240 GB. Debian
Bullseye will be installed on it once it's released, as my secondary
computer to use.
I have question regarding whole disk encryption. What technology should
I use, to have encrypti
On 6/28/21 1:36 PM, David Christensen wrote:
(Dell factory default for drives is 'RAID'; 'ACPI' may be required).
Correction: AHCI.
David
On 28/06/21 20.14, Dan Ritter wrote:
The second problem is that ssl_ca should point to the CA bundle
for your desired SSL cert -- in this case, your own CA.
It is probably indicative of something that the only mention of
ssl_ca_path in Dovecot's documentation is in a comment in the config.
Is
Perhaps it should be said that personal use of gpg and the use that a
system administrator makes of it and key-ing are different use-cases. So we
might expect fewer assumptions to hold and greater mystery :-)
On Sat, Jun 26, 2021, 1:53 PM wrote:
> On Sat, Jun 26, 2021 at 08:42:26AM -0400, Cindy
On Sun, Jun 27, 2021, at 8:33 AM, Peter Ehlert wrote:
> > X clients like MATE don't directly depend on an X server, because in
> > theory, the X server could be on a different machine.
I'd love to be able to do that! E.g. a headless machine with plenty of RAM and
CPU power to run Mate, but locat
Hi,
On 2021-06-28 10:12 p.m., Rick Thomas wrote:
> On Sun, Jun 27, 2021, at 8:33 AM, Peter Ehlert wrote:
>>> X clients like MATE don't directly depend on an X server, because in
>>> theory, the X server could be on a different machine.
>
> I'd love to be able to do that! E.g. a headless machine
On Mon, Jun 28, 2021 at 10:46:01PM -0400, Polyna-Maude Racicot-Summerside wrote:
> On 2021-06-28 10:12 p.m., Rick Thomas wrote:
> > I'd love to be able to do that! E.g. a headless machine with plenty of RAM
> > and CPU power to run Mate, but located in a locked building on the other
> > side of
> Along with SED, I suggest that you also implement Secure Boot.
Can someone give me pointers to actually known attacks (not
hypothetical ones, which I can invent myself without much difficulty)
that would have been prevented by Secure Boot?
I can see that subverting the early boot might be a goo
On Lu, 28 iun 21, 09:46:17, David Wright wrote:
>
> But your evening run of apt-get -y dist-upgrade was unconstrained,
> and so shim-signed could be removed because it was no longer being
> held onto as a Depends or Recommends.
Except that `apt-get dist-upgrade` doesn't do that (`autoremove`
22 matches
Mail list logo
