Hi, On Wed, Dec 31, 2008 at 02:35:46PM +0100, Michal Suchanek wrote: > On 31/12/2008, olafbuddenha...@gmx.net <olafbuddenha...@gmx.net> > wrote: > > On Tue, Dec 30, 2008 at 12:10:39PM +0100, Michal Suchanek wrote:
> If you want a POSIX system Coyotos is completely out of question. > > I would think that the kernel itself does not provide the constructor > primitive - I would make it a service on top of a simple kernel. Indeed the constructor is not part of the kernel itself AFAIK. But at the microkernel level, all mechanisms and design decisions are intertwined quite a lot: Changing one piece does have consequences in other places -- you have to rework pretty much the whole design. I don't know enough details to say for sure, but I'm rather positive that even if the constructor was the *only* thing we don't want, it still would make Coyotos unsuitable for us... > Yes, the system provides a service out of the box that provides DRM > memory which might be a step towards DRM content protection. I do not > like the feature but I have not seen a secure system design without > such feature, either. Well, as I explained, we believe that we can build a system providing the kind of security *we* are interested in, without such mechanisms. > > > If you cannot do something as root you cannot do it at all on the > > > system > > > > > > This is just wrong. Think of BSD secure levels for example: Certain > > things are protected when the system is running in the normal mode, > > but the administrator can still change them by starting it in a > > different secure level. > > You can shut down Coyotos and look at the on-disk image. As going to > less secure level from a more secure level can be only done by > rebooting there is not much difference here. As I said, SElinux uses a different approach, which doesn't require rebooting AFAIK; I only used the secure levels as an example to refute your claim that root permissions and admin permissions are inherently equivalent. More importantly, the fact that you can theoretically manipulate the disk image of a Coyotos installation, doesn't mean it's actually feasible in practice. This is a common theme in your arguments: You always say that this is possible and that is possible, totally ignoring the question how realistic things actually are. But as I already pointed out at the beginning of the discussion, this is the only really interesting question: because in theory, you pretty much can do anything you desire on pretty much any system, if you invest enough effort. What really distinguishes designs is only *how hard* certain things are with one design or the other. A good design is one that makes the things we are interested in straightforward; the properties we want to see natural. > > No, this is all that *you* seem to be interested in. Other people > > expect better integration between applications -- there is a reason > > things like dbus were created. > > I do not know why dbus was created and what problems it is trying to > solve. And I have no idea why a word processor would need to > communicate with any other application for example. There are > clipboards but these are not in dbus so I really don't know any use > case for typical application communicating through dbus with another > one. So you don't see the reasons. Great. "I don't see it, so it's not there!"... > > You are missing the point: There would still be no integration > > between applications running in the UNIX environment, with dbus and > > all, and "native" applications running in an environment knowing > > nothing about dbus. > > Why so? > > dbus uses streams for communication, and there sure is need for > streams in any system. I do not see how this does not fit. > > I would want to examine dbus and see if it can be modified to make > better use of the system or if it just tries to work around some > problems that could be solved differently on non-unix system but for > start there is no reason why its socket cannot be used by any > application. You are still missing the point. Of course you *can* make the "native" applications communicate with UNIX applications using dbus, if you implement dbus support -- just as you can implement any other UNIX facility to improve interaction with UNIX applications... But then, you end up implementing all these horrible ill-designed insecure UNIX things you wanted to get rid of in the first place! (From what I heard, dbus fits in with this category quite well.) Also, you are again ignoring the question of feasibility... There is no way you can have good integration of UNIX applications without using the UNIX facilities. I stand by my claim that when good integration of UNIX applications is top priority, the only useful approach is building around a POSIX environment. (As a reminder, this is not the only reason why we are doing so; it's just one of them.) -antrik-
