lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 07 Sep 2014 03:42:00 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	Lennart Sorensen <lsorense@...lub.uwaterloo.ca>
CC:	Rob Landley <rob@...dley.net>,
	Rogelio Serrano <rogelio.serrano@...il.com>,
	Borislav Petkov <bp@...en8.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Måns Rullgård <mans@...sr.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Christopher Barry <christopher.r.barry@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: OT: Open letter to the Linux World

Am 07.09.2014 01:44, schrieb Lennart Sorensen:

> So why C++ then if you care about making the code easy to make safe when
> there are clearly even better options.  Why not OCAML or Erlang or one
> of the other much more robust languages that don't contain all the
> dangers of C?

I would choose Prolog. ;)

I don't have to provide an answer because I'm not one of those which 
have gone out to change this critical part of many systems.

My concerns are that C is one of the worst languages for that. I'm not
saying that C++ would be the best solution. But I'm pretty sure it would 
have been a much better solution than C.

That means I haven't spend much time (around zero) to think about what 
an init-replacement has to do and how it would be done best. I'm just 
very concerned about what happens there.

So here are just some thoughts:

- Why do you call OCAML or Erlang more robust? Many problems in other 
languages just aren't well known because they are only used by a few 
people which don't tell you bad things about the language they've 
choosen. ;)

- Can you achieve all goals with just using OCAML or another language? 
My experience is that in almost all of those "very well designed 
languages", you are reaching very often some limits or problems which 
are very ugly to solve, if it's possible at all to solve them.

- How many people do you know which can program (and review) that language?

- How robust are the compilers/interpreters? How are they maintained? 
What happens if you find a bug in the compiler/interpreter?

But, as said above, I don't have to provide a solution because I'm not 
the one who has gone out to change PID 1 into something more complicated. ;)

Regards,

Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ