similar to: openssh (OpenBSD) , bsdauth and tis authsrv

I redid my previous OPIE patch for the current ssh tree. It seems to work fine here, and I'ld love to see it merged before the 3.0 release. Wichert. diff -x CVS -wNur ../cvs/other/openssh_cvs/Makefile.in openssh_cvs/Makefile.in --- ../cvs/other/openssh_cvs/Makefile.in Mon Oct 22 02:53:59 2001 +++ openssh_cvs/Makefile.in Sun Nov 4 01:18:19 2001 @@ -50,7 +50,7 @@ SSHOBJS= ssh.o

Hello, I problem is in the format of the date, my time series is like this: 2006070100 1244 61 62 2006070101 1221 60 60 2006070102 1214 60 60 2006070103 1194 59 59 2006070104 1182 58 58 2006070105 1178 58 58 2006070106 1176 58 58 2006070107 1173 58 58

Depending on an R computation I would like to include an Sweave documents in the main Sweave document. How can I do it? So I was thinking .... to use Latex features : \newif\ifpaper \ifpaper \SweaveInput{"my1.Rnw"} \else \SweaveInput{"my2.Rnw"} \fi But how do I set paper to true or false given an \Sexpr ?? \papertrue % or \paperfalse Any ideas? cheers -- Witold

Hello, I'm looking for a solution for the following problem: 1) I have a folder with several csv files; each contains a set of measurement values 2) The measurements of each file belong to a position in a two dimensional matrix (lets say "B02.csv" belongs to position 2,2 3) The size of the matrix is fix 4) I cannot assure to have a csv file for each position 5) Each position

From: "Marco Trevisan" <marco at ubuntu.com> This serie of patches have been already submitted via [1], but i'm sending them again to the ML, to see if they can get some more traction. The patches are already part of Ubuntu openssh since 24.04, and they basically allow proper immediate instruction reporting to clients using PAM (as per RFC4256). This follows the approach

Hi, Is there any hope getting openssh to support a sequence of several authentication methods (requiring different passwords) for one login? I.e. take the standard static password, feed it into pam_unix.so for verification, then ask the user for yet another password (e.g. a one-time password) and verify this one by a different PAM module Currently, verifying either a static password or a one time

Hi, I have question about __builtin_object_size behaviour. LLVM for __builtin_object_size function doesn't calculate correct value when pointer is used only in __builtin_object_size function call, and never after that. For this case LLVM as result generates 0 or -1 depends of second argument of __builtin_object_size function. Is this correct behaviour or it should work as gcc (gcc

Hi, [I sent this to the plyr mailing list (late) last night, but it seems to be lost in the moderation queue, so here's a shot to the broadeR community] Apologies in advance for being more verbose than necessary, but I'm not even sure how to ask this question in the context of plyr, so ... here goes. As meaningless as this might be to do with the `iris` data, the spirit of it is what

On Sun, Aug 20, 2017 at 2:47 AM, Ivan A. Kosarev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello Daniel, > > >>>> the type of (*x) is not compatible with the type of (*b) or, > >>>> recursively, type of b->i. Similarly, the type of (*b) is > >>>> not compatible with (*x) or, recursively, x->i. > >> ... >

It started out as "this'll be just a simple fix ..." and turned into something a bit over-engineered in the end. Here it is anyway. Rich.

Hi! This is an artifact of how LLVM works. Essentially, LLVM detects that `var` is unused and deletes it before it tries to lower the `llvm.objectsize` (which is what clang lowers `__builtin_object_size` to) call to a constant. While this isn't ideal, I don't think it realistically a problem, because `var` must be otherwise unused for this behavior to occur, and the whole purpose of

On Sun, Aug 20, 2017 at 8:54 AM, Ivan A. Kosarev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello Daniel, > > > The problem with the way you are trying to show this is that > > there are many ways to prove no-alias, and TBAA is one of them. > > The reason i stare at dump files and debug info is precisely to > > separate the TBAA portion from the rest.

Maybe security related mails should be sent elsewhere? I didn't notice any so here it goes: sender.c:receive_sums() s->count = read_int(f); .. s->sums = (struct sum_buf *)malloc(sizeof(s->sums[0])*s->count); if (!s->sums) out_of_memory("receive_sums"); for (i=0; i < (int) s->count;i++) { s->sums[i].sum1 = read_int(f);

c'est quoi cette chelouzerie ? je parle de l'ajout du sizeof(DWORD)... et ce que ce serait pas un str*n*cpy ou s*n*printf la vraie solution ? Arno 2012/5/3 Frederic BOHE <fbohe-guest at alioth.debian.org>: > Author: fbohe-guest > Date: Thu May ?3 08:31:38 2012 > New Revision: 3554 > URL: http://trac.networkupstools.org/projects/nut/changeset/3554 > > Log: >

I've read up some more on the subject, and it seems the proper way to do this with GCC is g++ and target attributes. I've refactored the patch that way, and it indeed uses SSSE3 automatically on supporting CPUs, regardless of the build host, so this should be ideal both for home builders and distros. Getting the code to build right in c++ mode (checksum_sse2.cpp only) was a bit of an

What do you base this on? Per https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html : "For the x86-32 compiler, you must use -march=cpu-type, -msse or -msse2 switches to enable SSE extensions and make this option effective. For the x86-64 compiler, these extensions are enabled by default." That reads to me like we're fine for SSE2. As stated in my comments, SSSE3 support must be

On 8/10/19 8:02 AM, Richard W.M. Jones wrote: > In a future commit we want to add (non-optional) Flags arg. As a step > to doing this, generalize OFlags so it's not tied to just > NBD_CMD_FLAG_*. > > This does not change the C API. > > It does introduce a small change to the OCaml API -- putting related > flags into a submodule, basically renaming them. Note we

Hi all, I am writing a xdelta-like application as a personal experiment and am busy implementing the rsync protocol, so far so good. I am using C++ templates and creating the algorithms so that operate on any stream, array, etc. through iterators. All seems well except that I am getting a lot of false hits with the weak checksum. When generating checksums of blocksize 1024 on the RedHat 7.1

This drop-in patch increases the performance of the get_checksum1() function on x86-64. On the target slow CPU performance of the function increased by nearly 50% in the x86-64 default SSE2 mode, and by nearly 100% if the compiler was told to enable SSSE3 support. The increase was over 200% on the fastest CPU tested in SSSE3 mode. Transfer time improvement with large files existing on both ends

This doesn't yet work. However it does make me more convinced than ever that we really need to sort out persistent buffer lifetimes in the library (similar to what we did for closures). Rich.