From: Scott Robert Ladd <coyote@coyotegulch.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: 2.7 thoughts: common well-architected object model
Date: Sat, 11 Oct 2003 13:00:27 -0400 [thread overview]
Message-ID: <3F88372B.1000209@coyotegulch.com> (raw)
In-Reply-To: <20031011160621.22378.qmail@web13006.mail.yahoo.com>
asdfd esadd wrote:
> So let me restate the need:
>
> * a unified well architected core component model
> which is extensible from OS services to application
> objects
>
> * the object model should be defined from the kernel
> layer for process/events/devices etc. up and not
> started at the application layer
A few years ago, I would have agreed with you. But in today's reality,
an OS-based object model provides a singular target for malicious attack.
The theory of reusable binary components is seductive, yet it leads to
many of the flaws seen in Windows. All too often, Windows applications
install components which may be newer or even older than the ones they
replace; while Microsoft has made strides with component versioning, the
problem still exists. These days, many Windows applications ship their
own version of "common" components, to avoid incompatibilities with
whatever may be installed system-wide.
OS-based object models also suffer from bit rot. New hardware and
software features require API changes, such that older objects gradually
become incompatible with newer requirements.
Windows also has the advantage of focusing on a single hardware
platform, where Linux runs on an incredible variety of systems.
Were Linux to implement an object model, it would need careful and
considerate design to address security, versioning, extensibility, and
portability.
--
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing
next prev parent reply other threads:[~2003-10-11 17:01 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-11 4:45 2.7 thoughts: common well-architected object model asdfd esadd
2003-10-11 14:30 ` Valdis.Kletnieks
2003-10-11 16:06 ` asdfd esadd
2003-10-11 16:48 ` Valdis.Kletnieks
2003-10-11 17:13 ` asdfd esadd
2003-10-11 17:38 ` Valdis.Kletnieks
2003-10-11 17:56 ` asdfd esadd
2003-10-11 18:20 ` Mark Hahn
2003-10-11 18:13 ` Zwane Mwaikambo
2003-10-11 23:33 ` J.A. Magallon
2003-10-11 17:00 ` Scott Robert Ladd [this message]
2003-10-11 17:57 ` Kenn Humborg
2003-10-11 18:34 ` asdfd esadd
2003-10-11 18:46 ` Valdis.Kletnieks
2003-10-11 19:01 ` Kenn Humborg
2003-10-11 19:11 ` retu
2003-10-11 19:25 ` viro
2003-10-12 11:59 ` Jamie Lokier
2003-10-12 16:04 ` retu
2003-10-12 16:44 ` Valdis.Kletnieks
2003-10-12 16:51 ` retu
2003-10-12 17:50 ` viro
2003-10-12 21:52 ` Jamie Lokier
2003-10-12 20:21 ` Rik van Riel
2003-10-13 20:21 ` James Antill
2003-10-14 5:01 ` retu
2003-10-14 6:00 ` Nick Piggin
2003-10-14 5:31 ` retu
2003-10-14 6:05 ` Tim Hockin
2003-10-14 6:46 ` viro
[not found] <Ft4B.3ML.3@gated-at.bofh.it>
[not found] ` <FutO.5TB.29@gated-at.bofh.it>
2003-10-11 17:03 ` Ihar 'Philips' Filipau
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=3F88372B.1000209@coyotegulch.com \
--to=coyote@coyotegulch.com \
--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