From: Willy Tarreau <w@1wt.eu>
To: Peter Teoh <htmldeveloper@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
kernelnewbies <kernelnewbies@nl.linux.org>
Subject: Re: RFC: Writing Solaris Device Drivers in Java
Date: Mon, 31 Mar 2008 07:56:18 +0200 [thread overview]
Message-ID: <20080331055618.GC23796@1wt.eu> (raw)
In-Reply-To: <47F0491F.4050804@gmail.com>
On Mon, Mar 31, 2008 at 10:14:55AM +0800, Peter Teoh wrote:
> Interesting read:
>
> http://research.sun.com/techrep/2006/smli_tr-2006-156.pdf
>
> Personal comments:
>
> Since KVM and Xen/OpenVZ etc other virtual machines are beginning to pop
> up - I don't see why it inhibits (in spite of the many initial
> difficulties as mentioned in the paper) the growth of using Java for
> device drivers development. Contrast it against udev - esp in terms of
> usability/supportability/extensibility etc. udev is a Linux thing,
> whereas Java is at industry level. If everyone write applications
> device drivers using Java (minus the extreme hardware arch specific
> stuff, but supports all the low level protocol specific stuff like
> TCP/IP, NFS, USB etc) then I think it has potential to compete against C
> lang - the monopolizer till today in the kernel world
> (Windows/MacOS/Linux/BSD etc). Ie, imagine using a drivers written for
> the Solaris in Linux, won't it be cool?
Oh fantastic! That way, we could have drivers which eat 1Gig of RAM for
almost nothing. Also, my experience with Java developers shows that what
Java really is is a way to lower the entry level in the development world.
That way, you can have completely incompetent people write complex
applications without even thinking that it will run on a real machine.
Most often, if it works in their IDE, they think it's OK to deploy (not
mentioning the fact that RFC compliance is far from being a problem in
these people's work). Of course, there are still real coders using this
language, and they may do great things (when the frameworks permit).
When you see salesmen announcing that their app will require about
400 GHz of CPU and half a TB of RAM to run, and noone even cares,
you understand there's a big problem with the way things are written
(the app that one was supposed to replace could run on 2 GHz of CPU
and 4 GB of RAM in the C version).
So please keep these technologies for sucking your nearby powerplant's
power and justifying your boss that you need a monster machine which
would make HPC people jealous, but I would hate it to make it easier
for the people I described above to pollute the kernel with their crap.
Willy
next prev parent reply other threads:[~2008-03-31 5:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-31 2:14 RFC: Writing Solaris Device Drivers in Java Peter Teoh
2008-03-31 2:59 ` Bernd Eckenfels
2008-03-31 3:13 ` Al Viro
2008-03-31 15:18 ` Peter Teoh
2008-03-31 15:52 ` Peter Teoh
2008-03-31 16:20 ` Ioan Ionita
2008-03-31 3:10 ` David Miller
2008-03-31 5:56 ` Willy Tarreau [this message]
2008-03-31 8:48 ` David Newall
2008-03-31 8:12 ` Benjamin Herrenschmidt
2008-03-31 10:28 ` Peter Zijlstra
2008-03-31 10:45 ` Wander Winkelhorst
2008-03-31 11:58 ` Jacek Luczak
2008-03-31 14:54 ` Peter Teoh
2008-04-01 12:51 ` Daniel Bonekeeper
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=20080331055618.GC23796@1wt.eu \
--to=w@1wt.eu \
--cc=htmldeveloper@gmail.com \
--cc=kernelnewbies@nl.linux.org \
--cc=linux-kernel@vger.kernel.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