public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alexander Holler <holler@ahsoftware.de>
To: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
Cc: "Rob Landley" <rob@landley.net>,
	"Rogelio Serrano" <rogelio.serrano@gmail.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Måns Rullgård" <mans@mansr.com>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Christopher Barry" <christopher.r.barry@gmail.com>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: OT: Open letter to the Linux World
Date: Sun, 07 Sep 2014 03:42:00 +0200	[thread overview]
Message-ID: <540BB7E8.3030907@ahsoftware.de> (raw)
In-Reply-To: <20140906234405.GA17692@csclub.uwaterloo.ca>

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

  reply	other threads:[~2014-09-07  1:42 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-12 19:38 OT: Open letter to the Linux World Christopher Barry
2014-08-12 20:21 ` Steven Rostedt
2014-08-12 20:44   ` Borislav Petkov
2014-08-12 22:07   ` Måns Rullgård
2014-08-13  8:27     ` Peter Zijlstra
2014-08-13  9:00       ` Borislav Petkov
2014-08-18 18:15         ` Alexander Holler
2014-09-04  7:54           ` Peter Zijlstra
2014-09-04 10:16             ` Alexander Holler
2014-09-04 14:36               ` Austin S Hemmelgarn
2014-09-04 17:29                 ` Alexander Holler
2014-09-04 17:58                   ` Austin S Hemmelgarn
2014-09-04 18:11                     ` Alexander Holler
2014-09-04 18:27           ` Rogelio Serrano
2014-09-04 18:33             ` Alexander Holler
2014-09-04 19:18               ` Rob Landley
2014-09-05  6:31                 ` Alexander Holler
2014-09-06 20:01                   ` Alexander Holler
2014-09-06 23:44                     ` Lennart Sorensen
2014-09-07  1:42                       ` Alexander Holler [this message]
2014-08-13  9:24       ` Måns Rullgård
2014-08-13  9:31         ` Peter Zijlstra
2014-08-13  9:37           ` Måns Rullgård
2014-08-13  9:37       ` Martin Steigerwald
2014-08-13  9:52         ` Peter Zijlstra
2014-08-13  9:59           ` Martin Steigerwald
2014-08-13  9:54         ` Peter Zijlstra
2014-08-13  9:57         ` Måns Rullgård
2014-08-13 10:21           ` Martin Steigerwald
2014-08-13 20:19       ` William Pitcock
2014-08-14  1:08 ` Robert Hancock
2014-08-15 18:41 ` Jaswinder Singh
2015-04-08 13:12 ` Denys Vlasenko
2015-04-09  0:37   ` Rob Landley
2015-04-09 18:18     ` Denys Vlasenko
2015-04-10 12:40     ` Rogelio M. Serrano Jr.
2015-04-10 21:20     ` Aaro Koskinen
2015-04-11  1:08       ` Rob Landley
     [not found] <E1XHxA6-0000ar-2a@feisty.vs19.net>
2014-08-15  8:59 ` Vlad Glagolev
2014-08-15 14:04   ` Gene Heskett
2014-08-16 21:10   ` Rob Landley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=540BB7E8.3030907@ahsoftware.de \
    --to=holler@ahsoftware.de \
    --cc=bp@alien8.de \
    --cc=christopher.r.barry@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lsorense@csclub.uwaterloo.ca \
    --cc=mans@mansr.com \
    --cc=peterz@infradead.org \
    --cc=rob@landley.net \
    --cc=rogelio.serrano@gmail.com \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox