headers
olafBuddenhagen | 2 Nov 00:30
Picon

Re: C++

Hi,

On Wed, Oct 28, 2009 at 10:53:56PM +0100, Bas Wijnen wrote:
> On Tue, Oct 27, 2009 at 09:48:17AM +0100, olafBuddenhagen <at> gmx.net
> wrote:

> Being able to make classes and do inheritance is definitely a Good
> Thing, for which there isn't a proper alternative in C, IMO.

I never worked on any code where inheritence was central enough to
warrant an extra language feature... There might be situations where it
is indeed (GUI programming is typically cited as the standard example)
-- but kernel hacking is definitely not one of them.

> In C, you would need to add the parent class as a first member, which
> would lead to variable.parent.parent.foo and variable.parent.bar.  If
> what you mean is inheritance (so top is just a specialized version of
> middle, which is a specialized version of base), then all those parent
> references are not adding information, but instead only obscuring
> things.

No, they are definitely *not* obscuring things. They make things more
explicit. Whether it is good or bad is a different question. (I for my
part consider it good in most cases.)

> > The fact that it's possible to use a certain subset that is pretty
> > elegant and consistent -- called C -- doesn't change the fact that
> > C++ as a language is dead ugly.
> 
> This subset isn't exactly C.  It's C with inheritance, member
(Continue reading)

Permalink | Reply | 15 comments |
headers
olafBuddenhagen | 1 Nov 23:05
Picon

Re: Coyotos

Hi,

On Wed, Oct 28, 2009 at 09:36:12AM -0700, Jonathan S. Shapiro wrote:
> On Mon, Oct 26, 2009 at 7:22 PM, <olafBuddenhagen <at> gmx.net> wrote:

> > But it wasn't the only problem. Other issues were the fully
> > synchnonous IPC, which is unsuitable for certain use cases --
> > including situation common in a UNIX environment;
> 
> There is unchallenged evidence in the literature that Linux on top of
> L4 (which, note, uses a fully synchronous IPC model) is *faster* than
> Linux running native, I wonder if you can cite concrete examples and
> back them up with something better than assertions.

Running a single-server on top of a microkernel is a very different
thing than running a multiserver system...

Anyways, Neal and Marcus discussed this with you in all detail; and for
all I know, you agreed at some point: in fact, you even consented to
change the IPC mechanisms in Coyotos -- although you took that decision
back later on...

> > ...and the completely different resource management approach.
> >
> The Coyotos kernel does not *have* a resource management approach. It
> provides naming and primitive protection for atomic system resources
> at the level of pages, but does not define any policy over those
> resources. Resource management is performed entirely at user level.

It seems rather clear to me from reading the Viengoos papers, that
(Continue reading)

Permalink | Reply | 0 comments |
headers
olafBuddenhagen | 1 Nov 22:49
Picon

Re: Hurd translators on FUSE

Hi,

On Wed, Oct 28, 2009 at 08:52:11PM +0200, Sergiu Ivanov wrote:
> On Tue, Oct 27, 2009 at 02:23:00AM +0100, olafBuddenhagen <at> gmx.net
> wrote:

> > feature on its own. Rather, I just explained them as an element of
> > the extensible VFS concept -- which is part of the Hurd's
> > fundamental idea of a user-extensible system environment. (And the
> > one I covered in most detail of course, as it's the most evident
> > part, with the most examples available.)
> 
> Hm, this is a good idea.  I guess I'll borrow this idea from you when
> I'll be delivering some Hurd-related presentation at my University (if
> you don't mind, of course).

Well, ideas are not copyrightable -- so unless you actually copy parts
of the talk (which is rather unlikely, considering that I never
published the files, nor was the talk recorded), I wouldn't have any say
in this anyways :-)

> Though. unfourtunately, I haven't yet run into an audience who know
> for sure what a kernel is, to tell nothing about FUSE or translators
> :-)

The thechnical details would be irrelevant of course to such an
audience. You could try selling it with other arguments though (which I
also mentioned in my talk): including the need for a pure GNU kernel;
the benefits of a GPLv3 option; and the fundamental idea of making user
freedom more practical at system functionality level.
(Continue reading)

Permalink | Reply | 1 comment |
headers
olafBuddenhagen | 2 Nov 00:44
Picon

Re: Broken dream of mine :(

Hi,

On Wed, Oct 28, 2009 at 09:42:13AM -0700, Jonathan S. Shapiro wrote:

> My one concern with Viengoos -- and I have expressed this to Neal many
> times -- is that in the pursuit of better resource arbitrage Neal has
> given up resource isolation, and there are fairly important (and
> unfortunate) security consequences for that. It is possible that these
> can be addressed, and it is fair to experiment on one thing at a time,
> but it needs to be clearly understood that Viengoos is an experimental
> kernel, and that it is *not* suitable in its current form for
> production use.

I'm pretty sure it's not worse at least than the systems people use for
production nowadays... While *some* improvement in this regard would
certainly be nice to have (and quite possible with Viengoos IMHO), it
was never really an explicit goal of the Hurd.

-antrik-
Permalink | Reply | 0 comments |
headers
olafBuddenhagen | 1 Nov 22:35
Picon

Re: sustainable development

Hi,

On Thu, Oct 29, 2009 at 11:50:52AM +0530, arnuld uttre wrote:
> > On Tue, Oct 27, 2009 at 5:04 AM,  <olafBuddenhagen <at> gmx.net> wrote:

> > In a true free software economy, no artificial scarcity need to be
> > created at all. Customers do not pay for the ability to use
> > particular "products" (not even indirectly through branding), but
> > rather for the further development of the software. Developers
> > charge for the actual work being done -- and once payed, the
> > availability of the results doesn't need to be restricted.
> 
> 
> and I thought RedHat model was in the true spirit of  running a free
> software business. They give the sources to anyone to do anything with
> it. So I don't think it matters if the CDs containing binaries are
> patented, I have the source. Though you are right in saying, people
> buy it because of "The Brand". As per experience Ubuntu and Red Hat
> are two worst distros I have ever experienced as Linux user,

That's rather subjective, and totally besides the point too. Also, the
models are very different: one of the fundamental ideas behind Ubuntu
was never to charge merely for the ability to obtain an "official" copy.
The support contracts from Canonical are entirely optional.

> 2nd, why would a customer will pay when gets binaries and sources and
> updates and everything ? (from the point of business)

If nobody pays development, no development takes place. And businesses
are generally interested to see improvements in the software (bug fixes
(Continue reading)

Permalink | Reply | 4 comments |
headers
William Leslie | 4 Nov 11:20
Picon
Gravatar

Re: C++

2009/11/2  <olafBuddenhagen <at> gmx.net>:
> Hi,
>
> On Wed, Oct 28, 2009 at 10:53:56PM +0100, Bas Wijnen wrote:
>> I've used Python for some larger projects.  It's a very nice language,
>> but I wouldn't consider it higher level than C++.
>
> Err... You are the first person I ever saw making such a claim.
>
> (I don't actually know Python, so I don't really have an opinion of my
> own... What I heard from other people made me place it as much more
> high-level than C++ though.)

I would call a language with any of closures, stronger typing,
namespaces, or automatic memory management higher level than C++.
Consistent dynamic dispatch, a metaclass model, and high-performance
built-in data types are also a bonus.

As a *bare minimum*, though, built-in automatic memory management
makes a big difference. I can't imagine doing application development
without it.

Disclaimer: pypy is the vehicle for my current research.

>> The nice thing about templates is that they really are very low-level.
>> This means they can actually be usable for kernel programming.  No
>> library support or magic compiler-generated code is required for them.
>> They do exactly what you expect.  But they are still capable of things
>> that become extremely ugly in C (you can choose from huge #define
>> blocks or lots of code duplication).
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michal Suchanek | 4 Nov 12:39
Picon
Favicon
Gravatar

Re: Broken dream of mine :(

2009/10/28 Jonathan S. Shapiro <shap <at> eros-os.com>:
> On Tue, Oct 27, 2009 at 8:05 PM, <olafBuddenhagen <at> gmx.net> wrote:
>>
>> Not sure what you are trying to say here. Both Coyotos an Viengoos do
>> resource management in userspace components...
>
>
> Correct.
>
>>
>> , but need the right kernel
>> primitives to be able to account resource usage and enforce the
>> distribution; and as the models differ quite a lot, so do the necessary
>> primitives AIUI.
>
> I don't think this is correct. Concrete example or evidence, please?
>
>>
>> > I don't think Neal made a bad choice, going with an established kernel
>> > (pistachio) as a base makes more sense than getting roped into
>> > maintaining one yourself (which may have happened had he used
>> > Coyotos), all things being equal.
>>
>> L4 was only (mis-)used as a hardware abstraction in the prototype
>> implementation of Viengoos. There is now also a proper native x86_64
>> implementation. It isn't based on L4 anymore -- and conceptually, never
>> really was.
>
>
> Neal made a good choice prototyping ideas on a pre-existing substrate.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Sam Mason | 4 Nov 12:58
Picon

Re: Broken dream of mine :(

On Wed, Nov 04, 2009 at 12:39:05PM +0100, Michal Suchanek wrote:
> This is not something that is completely addressed in Coyotos either -
> there still can be observable increase in latency when the system is
> under load. Coyotos aims to get nearer to the absolute isolation
> ideal, though.

AFAICT, it is possible to arrange things in Coyotos so that (say) things
don't get swapped to disk and that memory is always available for the
services that need it.  There were various discussions about this to do
with windowing systems; for example, you want to know that you'll always
be able to bring up a "task manager" to kill off offending processes,
hence a way of reserving the appropriate resources for this in advance
is needed.  This example involves quite complicated interactions between
lots of different services needed to do its work and arranging all this
is somewhat difficult.

--

-- 
  Sam  http://samason.me.uk/
Permalink | Reply | 2 comments |
headers
William Leslie | 4 Nov 14:59
Picon
Gravatar

Re: Broken dream of mine :(

2009/11/4 Michal Suchanek <hramrach <at> centrum.cz>:
> 2009/10/28 Jonathan S. Shapiro <shap <at> eros-os.com>:
>> My one concern with Viengoos -- and I have expressed this to Neal many times
>> -- is that in the pursuit of better resource arbitrage Neal has given up
>> resource isolation, and there are fairly important (and unfortunate)
>> security consequences for that. It is possible that these can be addressed,
>> and it is fair to experiment on one thing at a time, but it needs to be
>> clearly understood that Viengoos is an experimental kernel, and that it is
>> *not* suitable in its current form for production use.
>>
>
> The main difference as I understand it is that Coyotos enforces 'hard'
> resource allocation - the resource either is allocated to the process
> or it is not.

I would probably say that "the resource is allocated or not".
Ownership is not addressed by the Coyotos model, quite simply whoever
has the capability to it can use the resource. The question of who
pays is not part of the core.

When you allocate a resource, you do so by invoking some authority.
This authority does not, at least in the case of the core servers,
specify how the resource is to be divided or shared: that
functionality must be implemented by the servers that implement that
user resource.

Capabilities that specify actual hardware allocation, the kind that
are dealt with by Coyotos, should probably be proxied by the operating
system and not handed out directly. The operating system should do as
Viengoos does: turn invocations of capabilities to relative time
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michal Suchanek | 4 Nov 15:02
Picon
Favicon
Gravatar

Re: Broken dream of mine :(

2009/11/4 Sam Mason <sam <at> samason.me.uk>:
> On Wed, Nov 04, 2009 at 12:39:05PM +0100, Michal Suchanek wrote:
>> This is not something that is completely addressed in Coyotos either -
>> there still can be observable increase in latency when the system is
>> under load. Coyotos aims to get nearer to the absolute isolation
>> ideal, though.
>
> AFAICT, it is possible to arrange things in Coyotos so that (say) things
> don't get swapped to disk and that memory is always available for the
> services that need it.  There were various discussions about this to do
> with windowing systems; for example, you want to know that you'll always
> be able to bring up a "task manager" to kill off offending processes,
> hence a way of reserving the appropriate resources for this in advance
> is needed.  This example involves quite complicated interactions between
> lots of different services needed to do its work and arranging all this
> is somewhat difficult.

You have completely missed the point. Even in Coyotos if you did not
pin your pages in memory so that they never get "swapped out" (and
most applications should not be able to pin) then your pages are much
more likely to get "swapped out" when other applications run (and
touch their pages)  than when the system is idle. While the "swap in"
may be transparent the latency is observable so you generally get the
same kind of information you get in Viengoos by observing the amount
of surplus memory available to you.

The ability to terminate processes is completely unrelated to this and
in any system that does reasonable resource management it is trivial
to implement. Most systems in use today do not guarantee the ability
to terminate rogue processes but that is a completely different issue.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane