[lkml]   [1998]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 2.1.97] more capabilities support
    Albert D. Cahalan wrote:
    > >> I believe we were discussing POSIX capabilities, not pure capabilities.
    > >>
    > >> I'll mail you about the pure capabilities later, but it appears that
    > >> they are fairly useless outside of an environment like EROS:
    > >> persistent system image, long-lived processes, NO FILESYSTEM, and
    > >> every scrap of data is an object associated with some code.
    > >
    > > You haven't even looked at the design:)
    > I kept asking you for one (in private email)... where is it?

    It's on the URL that I gave you and that you haven't even looked at
    (it's obvious because the page also includes notes on design of a UNIX
    compatible system on top of pure capabilities).

    > > All the features that you have named are because of a different design
    > > of the operating system, don't you agree? So isn't it perhaps time that
    > > we start to consider alternative concepts for mainstream operating
    > > systems or at least start implementing known solutions to problems that
    > > our systems have?
    > It is interesting, and perhaps it is useful for some people.
    > It is _not_ anything like Linux and can't support basic POSIX
    > features very well. For example, you have to give up much of
    > the security and run Unix emulation if you want a real filesystem.
    > (yeah, no kidding: we get rid of open(2) and just pass fd's around)

    You talk about the filesystem as something that is fundamentally a good
    thing (which it is not). It's just the current way of ensuring the
    persistency of data because we're not able to achieve general
    persistency. A filesystem can _easily_ be emulated if you have general
    persistency of objects (it's just an object that contains hierarchically
    organized smaller objects), although once you have general persistency,
    you don't _want_ to take a step back and implement a subsystem that has
    been the source of numerous security holes. Also, the filesystem wastes
    a lot of the disk's potential performance. If you on the other hand do
    periodic snapshots of the system memory, the writes to the disk can be
    done very fast (close to the maximum), because you don't have to seek
    all the time but you simply dump the whole memory as a one block write
    (or several consecutive ones).

    In the same sentence, you claim that pure capabilities can't support
    basic POSIX features very well. What are those basic features? And if
    they can't be supported but a better alternative is provided at the same
    time, why _should_ they be supported? And exactly what security has to
    be given up if pure capabilities are good exactly because, among other
    things, they provide _better_ security???

    As for open(), you really picked a stupid example to show 'disadvantages
    of pure capabilities'. Wouldn't it be an _optimization_ if you could get
    rid of a neccessary step of opening a file and just access it directly?

    > >> I hope everyone has seen this by now:
    > >>
    > >
    > > Yes, we have seen it, but the thesys is in German
    > I thought people were complaining about the web page in German.
    > I just assumed everybody would grab to code itself, not the thesis.

    Code is just the implementation of the concept. If the concept is
    flawed, don't you think that the implementation will be fundamentally
    flawed too?

    I appologize if this mail may seem as a bit of flaming, but it really
    annoys me if people put down designs without at least _trying_ to
    understand them. I would be very happy if someone could provide me with
    real arguments, why capability lists and ACLs are better than pure
    capabilities (I assume Linux kernel developers think so because it seems
    that they prefer those designs).


    PS: There's an intresting saying that I saw at the bottom of some page
    about pure capabilities: Let's argue to learn, not to win..

    Andrej Presern,

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

     \ /
      Last update: 2005-03-22 13:42    [W:0.028 / U:2.404 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site