emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nick Dokos <nicholas.dokos@hp.com>
To: emacs-orgmode@gnu.org
Cc: nicholas.dokos@hp.com
Subject: Re: Regression in `org-todo'
Date: Mon, 02 Apr 2012 17:40:49 -0400	[thread overview]
Message-ID: <7135.1333402849@alphaville> (raw)
In-Reply-To: Message from Michael Strey <mstrey@strey.biz> of "Mon, 02 Apr 2012 22:44:13 +0200." <20120402204413.GD1704@mischka.fritz.box>

Michael Strey <mstrey@strey.biz> wrote:

> Hi Bastien,
> On Mon, Apr 02, 2012 at 05:03:04PM +0200, Bastien wrote:
> > ...
> > Please test against latest HEAD and tell me if your problem is still
> > here, it shouldn't.
> I confirm that the problem is solved.  Thank you!
> It's interesting to see how a bug in a module from the contrib path can
> cause strange behaviour of org-mode's core functions.

There is no distinction between contrib and core. Once a module is
loaded (wherever it comes from), it is part of emacs and can cause all
kinds of damage: not just to org, but to the whole running emacs. It's
the price one pays for the convenience of dynamically loading code.  You
can avoid the danger by not loading modules, but then emacs becomes much
less interesting: after all, the "e" stands for "extensible".

And it's not just emacs: if you load a module in linux, it can muck
around with kernel memory and crash your system in no time at all.

The whole microkernel approach was an attempt to have that cake and eat
it too: safely loading modules (they run in a separate address space and
can't touch core kernel memory). Nobody has found a way to make it as
fast as a monolithic kernel though (although people have argued forever
about it: the Tanenbaum-Torvalds debate centered exactly around that
point - after you subtract the flaming).


  parent reply	other threads:[~2012-04-02 21:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-01 15:01 Regression in `org-todo' Moritz Ulrich
2012-04-01 18:35 ` [URGENT] " Moritz Ulrich
2012-04-01 20:29   ` Bastien
2012-04-01 20:37     ` Bastien
2012-04-02 14:54 ` Michael Strey
2012-04-02 15:03   ` Bastien
2012-04-02 20:44     ` Michael Strey
2012-04-02 21:07       ` Bastien
2012-04-02 21:43         ` Nick Dokos
     [not found]       ` <mstrey@strey.biz>
2012-04-02 21:40         ` Nick Dokos [this message]
2012-04-02 22:40           ` Bastien
2012-04-02 23:18             ` Bernt Hansen

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:

  List information: https://www.orgmode.org/

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

  git send-email \
    --in-reply-to=7135.1333402849@alphaville \
    --to=nicholas.dokos@hp.com \
    --cc=emacs-orgmode@gnu.org \


* 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.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).