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 Tue, Jun 3, 2014 at 7:10 AM, Theodore Ts'o ty...@mit.edu wrote:
There's a very simple solution to that problem, especially since we
now have the support and attention of many hardware companies. The
rule should be very simple. If a company doesn't contribute either
(a) exclusive,
especially Stephen Henson, who has kept it together in much the same way as
Keith Richards did the Stones.
With no disrespect intended to either man, I have to say that this is an
analogy that never would have occurred to me in a million years.
/r$
--
Principal Security Engineer
I don't disagree (or I certainly don't disagree completely) with anything
that has been said so far. But I think it's easy to assign disproportionate
angst to this or that problem.
For example, and that's all this is, but one of the most serious issues I
think we have in the openssl code is that
It's a simple solution, and obvious and I don't think it'll work.
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.
OpenSSL doesn't. Yes, it
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
Hi,
Which platforms are deprecaded an could/should be removed in the
sourcecode?
MS-DOS?
Windows 16 Bit?
OS/2?
Windows 95/98/ME?
Windows NT/2000/XP?
Necessary criteria for a platform to be included in the first list would be:
* Currency, i.e. a platform is widely
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
The other thing to consider is that perhaps OpenBSD really has the
right approach, which is that portability should be done via support
libraries, and not part of the core code. That might impact
performance on some legacy piece of cr*p, but presumably, impacted
performance is better than no
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.
(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.
This ISN'T the Linux kernel. It's userspace code and longer lived and wider
spread than Linux and pretty fundamental to security.
Even with the 'dead' platforms crossed out,
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
Look at the sources.
The build related mess is mainly Windows support.
#ifdef hell is mainly around external engine support, asm to get
performance, or object sizes/endianess which intrinsically varies platform
to platform. The code was written over a lot of years with a lot of
different styles
13 matches
Mail list logo
