similar to: Compile problem on Solaris

On 10/06/2019 14:40, Roderick Johnstone via dovecot wrote: > Compiling dovecot 2.2.36.1 with the native compiler on Solaris 10 is > giving the error below. ... > -m64 -c -o sha3.lo sha3.c > libtool: compile:? cc -DHAVE_CONFIG_H -I. -I../.. > -I/export/home/exim_build_20190605/build_local/include -m64 -c sha3.c > -KPIC -DPIC -o .libs/sha3.o > "sha3.h", line 49:

On 2/13/19 1:23 AM, Matthias Fechner via dovecot wrote: > > > Am 13. Februar 2019 00:34:15 schrieb Robert Moskowitz > <rgm at htt-consult.com>: > >> On 2/12/19 6:03 PM, Matthias Fechner via dovecot wrote: >>> Am 12.02.2019 um 17:05 schrieb Robert Moskowitz via dovecot: >>>> I have trying to find how to set the dovecot-sql.conf for using

On 2/13/19 8:30 AM, Aki Tuomi wrote: > On 13.2.2019 15.18, Robert Moskowitz via dovecot wrote: >> >> On 2/13/19 1:23 AM, Matthias Fechner via dovecot wrote: >>> >>> Am 13. Februar 2019 00:34:15 schrieb Robert Moskowitz >>> <rgm at htt-consult.com>: >>> >>>> On 2/12/19 6:03 PM, Matthias Fechner via dovecot wrote:

On 2/13/19 8:30 AM, Aki Tuomi wrote: > On 13.2.2019 15.18, Robert Moskowitz via dovecot wrote: >> >> On 2/13/19 1:23 AM, Matthias Fechner via dovecot wrote: >>> >>> Am 13. Februar 2019 00:34:15 schrieb Robert Moskowitz >>> <rgm at htt-consult.com>: >>> >>>> On 2/12/19 6:03 PM, Matthias Fechner via dovecot wrote:

Jean-Daniel Dupas via dovecot wrote: > > >> Le 13 f?vr. 2019 ? 14:54, Robert Moskowitz via dovecot >> <dovecot at dovecot.org <mailto:dovecot at dovecot.org>> a ?crit : >> >> >> >> On 2/13/19 8:30 AM, Aki Tuomi wrote: >>> On 13.2.2019 15.18, Robert Moskowitz via dovecot wrote: >>>> >>>> On 2/13/19 1:23 AM,

On Wed, May 8, 2013 at 7:33 PM, Rui Ueyama <ruiu at google.com> wrote: > On Wed, May 8, 2013 at 10:29 AM, Shankar Easwaran <shankare at codeaurora.org > > wrote: > >> On 5/8/2013 11:35 AM, Chandler Carruth wrote: >> >>> Interestingly newer, supposedly "more secure" digest algorithms are also >>> very often significantly faster. I

On Wed, May 8, 2013 at 9:13 PM, Owen Anderson <resistor at mac.com> wrote: > On May 8, 2013, at 10:50 AM, Chandler Carruth <chandlerc at google.com> > wrote: > > >> >>> What are the SHA-3 variants that you think would suite these needs ? >> >> > I want to look at the implementation complexity. The winner (and the > official SHA3 algorithm),

On May 8, 2013, at 10:50 AM, Chandler Carruth <chandlerc at google.com> wrote: > > What are the SHA-3 variants that you think would suite these needs ? > > I want to look at the implementation complexity. The winner (and the official SHA3 algorithm), BMW and Skein are all worth looking at. If your primary criterion is through-put on large, desktop-class CPUs, Skein is likely

On 2/12/19 6:03 PM, Matthias Fechner via dovecot wrote: > Am 12.02.2019 um 17:05 schrieb Robert Moskowitz via dovecot: >> I have trying to find how to set the dovecot-sql.conf for using >> SHA256/512.? I am going to start clean with the stronger format, not >> migrate from the old MD5.? It seems all I need is: > you maybe would like to have a look to the hashing algo

On 13.2.2019 15.18, Robert Moskowitz via dovecot wrote: > > > On 2/13/19 1:23 AM, Matthias Fechner via dovecot wrote: >> >> >> Am 13. Februar 2019 00:34:15 schrieb Robert Moskowitz >> <rgm at htt-consult.com>: >> >>> On 2/12/19 6:03 PM, Matthias Fechner via dovecot wrote: >>>> Am 12.02.2019 um 17:05 schrieb Robert Moskowitz via

Hello everybody, First a big thanks for tinc-vpn I am still using it next to wireguard and openvpn. I am having a setup where the tinc debian appliance is at 100% cpu load doing about 7.5MB/s. Compression = 9 PMTU = 1400 PMTUDiscovery = yes Cipher = aes-128-cbc How can I pick a cipher that is the fasted for my CPU and don't create a CPU bottleneck at 100%. Kind regards, Jelle de Jong

> Le 13 f?vr. 2019 ? 14:54, Robert Moskowitz via dovecot <dovecot at dovecot.org> a ?crit : > > > > On 2/13/19 8:30 AM, Aki Tuomi wrote: >> On 13.2.2019 15.18, Robert Moskowitz via dovecot wrote: >>> >>> On 2/13/19 1:23 AM, Matthias Fechner via dovecot wrote: >>>> >>>> Am 13. Februar 2019 00:34:15 schrieb Robert Moskowitz

On 5/8/2013 11:35 AM, Chandler Carruth wrote: > Interestingly newer, supposedly "more secure" digest algorithms are > also very often significantly faster. I don't think we want any of the > ones mentioned here, I think we want one of the candidates is the SHA3 > competition which had truly stellar software implementation > throughput. I'm hoping to add support

https://dovecot.org/releases/2.2/dovecot-2.2.27.tar.gz https://dovecot.org/releases/2.2/dovecot-2.2.27.tar.gz.sig Note that the download URLs are now https with a certificate from Let's Encrypt. * dovecot.list.index.log rotation sizes/times were changed so that the .log file stays smaller and .log.2 is deleted sooner. + Added mail_crypt plugin that allows encryption of stored emails.

https://dovecot.org/releases/2.2/dovecot-2.2.27.tar.gz https://dovecot.org/releases/2.2/dovecot-2.2.27.tar.gz.sig Note that the download URLs are now https with a certificate from Let's Encrypt. * dovecot.list.index.log rotation sizes/times were changed so that the .log file stays smaller and .log.2 is deleted sooner. + Added mail_crypt plugin that allows encryption of stored emails.

On Sun, 17 Feb 2019 at 11:34, Marc Weustink via dovecot <dovecot at dovecot.org> wrote: > Jean-Daniel Dupas via dovecot wrote: > > > > > >> Le 13 f?vr. 2019 ? 14:54, Robert Moskowitz via dovecot > >> <dovecot at dovecot.org <mailto:dovecot at dovecot.org>> a ?crit : > >> > >> > >> > >> On 2/13/19 8:30 AM, Aki

On Wed, May 8, 2013 at 10:29 AM, Shankar Easwaran <shankare at codeaurora.org>wrote: > On 5/8/2013 11:35 AM, Chandler Carruth wrote: > >> Interestingly newer, supposedly "more secure" digest algorithms are also >> very often significantly faster. I don't think we want any of the ones >> mentioned here, I think we want one of the candidates is the SHA3

On Wed, May 8, 2013 at 6:03 PM, Rui Ueyama <ruiu at google.com> wrote: > I'd use SHA128 or MD5 as the linker does not handle hostile input. I think > as long as it's collision free, it should suffice. FWIW, the need for a collision free hash -- or *digest*, my preferred term -- is well known. Interestingly newer, supposedly "more secure" digest algorithms are also

Hi, Below is a document detailing changes we'd like to make to Clang/LLVM to improve the usability of the target options for ARM and AArch64. To keep things simple the proposed changes are listed at the start and you can find the supporting examples at the end of the document. I look forward to your feedback. Thanks, David Spickett. RFC New Clang target feature selection options for

When I pass an empty string for cpu and features to createTargetMachine, and then use LLVMGetTargetMachineCPU() and LLVMGetTargetMachineFeatureString() to get the strings back, they are still empty. Is there a way to have llvm compute the effective cpu/features string, and provide it so that I can inspect it? I'm trying to figure out how the cpu/features string that I am explicitly passing,