9ac03675010a69507c0a9d832d6a722e07d35cc6
merged tag 'ext4_for_linus_stable'
gpg: Signature made Sun 20 Apr 2014 10:23:16 PM EDT using RSA key ID C11804F0
gpg: Good signature from Theodore Ts'o ty...@mit.edu
gpg: aka Theodore Ts'o ty...@debian.org
gpg: aka Theodore Ts'o ty
On Sat, Apr 26, 2014 at 06:00:44PM +0200, Kurt Roeckx wrote:
That's for the merge commit. But I assume that all the patches
that got merged are now visible in Linus's tree with authors
different than Linus.
Of course. That's because it was their work, and their commits.
It may be that the
On Mon, Jun 02, 2014 at 03:38:22PM +0200, stefan.n...@t-online.de wrote:
* How much do you gain by removing support for the platform?
Is there any relevant amount of code, that is really NT/2000/XP specific
and unneeded for newer Windows releases? Breaking the support for
the ancient
On Tue, Jun 03, 2014 at 11:22:58AM +1000, Peter Waltenberg wrote:
I won't argue that sometimes legacy support makes the code hard to read,
but in itself I don't think it's causing bugs.
The OpenBSD people are right here. If it's hard to read, then we
don't have many eyeballs on the code.
On Tue, Jun 03, 2014 at 12:20:17PM +1000, Peter Waltenberg wrote:
(c) EBCDIC.
z/OS is still alive. I'll concede that one is weird and hard to get hold
of, but it has a lot of users still.
z/OS supports ASCII, and UTF-8, and has its own conversion routines
built into the system. So it's not
On Tue, Jun 03, 2014 at 02:22:07PM +1000, Peter Waltenberg wrote:
One of the uglier problems is that unless you can build/test on all the
platforms on each change you'll almost certainly break platforms
unexpectedly - that lack of hardware has been one of the long term problems
and it's
On Wed, Jun 04, 2014 at 09:14:18AM +1000, Peter Waltenberg wrote:
This is NOT the Linux kernel, the Linux kernel is directly funded by
several of the larger companies, they have employees contributing directly
on the kernel, with access to internal hardware resources.
Yes, and I'm saying
On Tue, Jul 01, 2014 at 12:37:31PM +0100, Matt Caswell wrote:
I just started to wonder, will soon come the time when my patches
will be also refused with the unsupported platform comment?
Our soon-to-be-released roadmap has this to say on supported platform:
* Currency, i.e. a platform
On Tue, Jul 01, 2014 at 02:10:31PM -0400, Mike Bland wrote:
I was wondering why 'make depend' output was saved in the Makefiles.
So I guess adding the .d files to the repository and using include
statements in the Makefiles is a reasonable possibility? (That's the
angle I'm taking with my
On Thu, Jul 03, 2014 at 04:01:16PM +0400, Loganaden Velvindron wrote:
I see such trends as leading to dangerous situations in the future.
OpenSSL is widely deployed, and the developers appear to grow older,
according to the various interviews I read. (I don't wish to offend
any of you guys
On Wed, Jul 09, 2014 at 06:20:49PM +0100, Ben Laurie wrote:
On 9 July 2014 14:38, Paul Morriss paul.morr...@tokenbay.co.uk wrote:
I am keen to get more involved in the development of OpenSSL, I am curious,
has the code been run through a static analysis tool (such as Coverity)?
Coverity do
On Sun, Jul 13, 2014 at 12:23:07PM -0500, Steven M. Schweda wrote:
From: Richard Levitte rich...@levitte.org
According to the comments, it sounds like HP C V7.3 ECO01 fixes the
problems. Do I get that wrong? If I don't, it seems that HP has, in
fact, provided a compiler without this
Perhaps a good model to take would be how the Linux kernel hands
ancient stable kernels. After a while, Greg K-H stops supporting a
long-term stable kernel. In some cases, a volunteer will step up and
continue supporting some ancient kernel. Those ancient kernels don't
get all bug fixes, and
On Sat, Mar 25, 2017 at 07:47:23PM +0100, Carlos Alberto Lopez Perez wrote:
> Unfortunately, dynamically linking is not a solution.
>
> My understanding is that the GPLv2 considers any library used by the
> GPLv2 program (it doesn't make a difference between dynamic or static
> linking) part of
On Wed, Jun 28, 2017 at 08:15:20AM +0100, Cory Benfield wrote:
> When you say “the linked article”, do you mean the PCWorld one?
> Because that article doesn’t provide any suggestion that
> /dev/urandom has anything to do with it. It is at least as likely
> that the SSH key is hard-coded into the
On Tue, Jun 27, 2017 at 06:55:47PM +, Salz, Rich via openssl-dev wrote:
> Getrandom() is a syscall, and I have concerns about the syscall
> performance. I would rather feed getrandom (or /dev/random if
> that’s not available) into a FIPS DRBG generator.
What is your concerns about syscall
On Wed, Jun 28, 2017 at 11:41:11AM +1000, Peter Waltenberg wrote:
> And FYI. On systems not backed with hardware RNG's /dev/random is
> extremely slow. 1-2 bytes/second is a DOS attack on it's own without any
> other effort required.
Please, stop suggesting the use /dev/random. The right
On Wed, Jun 28, 2017 at 01:50:49AM +, Salz, Rich wrote:
> That's interesting info Ted, thanks. But we don't currently know
> anything about which kernel or glibc version we're building for;
> maybe that has to change. (We barely, and rarely, look at the
> toolchain version.) And we need to
On Tue, Jun 27, 2017 at 09:02:54PM +, Salz, Rich wrote:
> > What is your concerns about syscall performance? What are your
> > performance requirements? I can tell you that Chrome has been using
> > /dev/urandom
>
> Well, Chrome ultimately works at human-scale. On the server side,
On Tue, Jun 27, 2017 at 04:12:48PM -0500, Benjamin Kaduk wrote:
>
> While you're here, would you mind confirming/denying the claim I read
> that the reason the linux /dev/random tracks an entropy estimate and
> blocks when it gets too low is to preserve backward security in the face
> of attacks
20 matches
Mail list logo
