On Mon, Feb 19, 2001 at 03:14:43PM +0100, Johan Rydberg wrote:
> "Eray Ozkural (exa)" wrote:
> Don't you mean Berkeley? Well, here's an URL to the Sprite project at
> Berkeley:
>
> http://www.cs.berkeley.edu:80/projects/sprite/sprite.html
Arrgh. Sure, Berkeley... The project is over but some
"Eray Ozkural (exa)" wrote:
> > > You mean a burst transfer. That's done in parallel programming. Many high
> > > level libraries take advantage of that. It is ultimately the task of
> > > message passing subsystem though. Think an optimizing msg handler. Of
> > > course you need some abstraction
> > By the way Elliot Lee, the instigator of the ORBit
> > project, thinks that he can, without violating the
> > CORBA spec, get the cost of a CORBA call darn
> close to
> > that of a standard library call, where a local
> > implementation of the requested service is
> > available.
>
> Do you ha
On Wed, Feb 14, 2001 at 03:21:16AM +0100, Farid Hajji wrote:
> > We're talking about a microkernel arch, but still I'm
> > not sure if turning hurd into gnome is a good idea.
> [...]
> > Interoperability is a good idea, but if you bloat the
> > whole code with interoperability stuff then it blows
> We're talking about a microkernel arch, but still I'm
> not sure if turning hurd into gnome is a good idea.
[...]
> Interoperability is a good idea, but if you bloat the
> whole code with interoperability stuff then it blows up.
You can add as much interoperability stuff between apps.
if you wis
On Sun, Feb 11, 2001 at 03:04:48PM +0200, Eray Ozkural (exa) wrote:
> Marcus Brinkmann wrote:
> >
> > I think it is single server, not multi server. There are many single server
> > systems, and they share the same deficiencies as monolithical kernels.
> > The linux kernel is also "modular", the
Mridul Jain wrote:
> > Anyway, those
> > people have been there'n' done that, and AFAIK they
> > aren't trying to
> > facilitate a multi-language development for their
> > modular
> > kernels, why not?
>
> Come on let's not bring in Billy here.Ok you can be
> happy coding in VB thro'out.
>
Bill
Marcus Brinkmann wrote:
>
> I think it is single server, not multi server. There are many single server
> systems, and they share the same deficiencies as monolithical kernels.
> The linux kernel is also "modular", the term is not clear and as thus it is
> confusing to use it.
Let me just confes
Ognyan Kulev wrote:
>
> On Sat, Feb 10, 2001 at 04:15:16PM +0200, Eray Ozkural wrote:
> > On Sat, Feb 10, 2001 at 03:12:46PM +0200, Ognyan Kulev wrote:
> > > One beautiful solution will be batching many IPC requests in one context
> > > switch, e.g. (open,read,close).
> >
> > You mean a burst tra
On Thu, Feb 08, 2001 at 04:31:54AM -0800, Mridul Jain wrote:
>
> hi,
> > > I can notice the messages as they are being sent
> > on this GNOME
> > > desktop. That would not make a good bet for a hurd
> > server.
> >
> > IMHO CORBA can be as fast as Mig, even faster.
> >
> yes I agree that IPC is
hi
> Merging the
> efforts with GNOME project will be A Good Thing
> (GConf, ...) - I see it as
> the most progressive GNU project (Unix sucks, but
> we'll fix it:-))).
Yes that is a powerful thing.Especially since ORBIT is
a good choice for such a stuff,I think GNOMERS will be
very interested.Le
On Fri, Feb 09, 2001 at 05:58:33PM +0200, Eray Ozkural (exa) wrote:
> Well he said performance is not really an issue,
Sorry, but I must insist to be pedantic here. I said that performance is not
a concern, not that it is not an issue. Performance is very important, but I
don't think one needs to
On Sat, Feb 10, 2001 at 04:15:16PM +0200, Eray Ozkural wrote:
> On Sat, Feb 10, 2001 at 03:12:46PM +0200, Ognyan Kulev wrote:
> > One beautiful solution will be batching many IPC requests in one context
> > switch, e.g. (open,read,close).
>
> You mean a burst transfer. That's done in parallel pr
On Sat, Feb 10, 2001 at 03:12:46PM +0200, Ognyan Kulev wrote:
> One beautiful solution will be batching many IPC requests in one context
> switch, e.g. (open,read,close).
You mean a burst transfer. That's done in parallel programming. Many high
level libraries take advantage of that. It is ultim
On Fri, Feb 09, 2001 at 04:11:19PM +0100, Marcus Brinkmann wrote:
> Of course, but any message passing only adds a constant overhead to a single
> message. Performance increase can also be achieved by adding new interfaces,
> which remove the need to send several messages (by replacing them with a
From: Marcus Brinkmann <[EMAIL PROTECTED]>
Subject: Re: MIG->Corba (performance)
Date: Fri, 9 Feb 2001 16:11:19 +0100
> Of course, but any message passing only adds a constant overhead to a single
> message. Performance increase can also be achieved by adding new interfaces,
>
--- "Eray Ozkural (exa)" <[EMAIL PROTECTED]>
wrote:
> Well he said performance is not really an issue, but
> this
> is one thing that linux people have been bashing
> hurd with.
> Performance has always been a primary design
> objective in OS
> design.
Well don't you assume that the performance
On Fri, Feb 09, 2001 at 05:58:33PM +0200, Eray Ozkural (exa) wrote:
> Well he said performance is not really an issue, but this
> is one thing that linux people have been bashing hurd with.
> Performance has always been a primary design objective in OS
> design.
I my experience Linux zealots who
Mridul Jain wrote:
>
> Hey things are cool!!It's just a useful discussion.:-)
>
All right :)
> > So, you're saying that a well optimized ORB can be
> > just as good as MIG.
> > That raises two other questions:
> > 1) Is CORBA going to be as slow as MIG?
> > 2) Is MIG slow enough?
>
> I th
On Fri, Feb 09, 2001 at 03:36:37PM -0500, Ingmar Schuster wrote:
> > Performance is not really the concern here, although it is good to know
> > that
> > a CORBA implementation can make special short cuts on the Hurd.
>
> Isn't it? IMHO such an important interface defenitely should be fast.
Of c
> Performance is not really the concern here, although it is good to know
> that
> a CORBA implementation can make special short cuts on the Hurd.
Isn't it? IMHO such an important interface defenitely should be fast.
Ingmar Schuster
___
Bug-hurd mai
hi,
> Please take my comments lightly, they are meant to
> be humorous to
> an extent. [no flames intended]
Hey things are cool!!It's just a useful discussion.:-)
> So, you're saying that a well optimized ORB can be
> just as good as MIG.
> That raises two other questions:
> 1) Is CORBA goin
> "Joshua" == Joshua Rosen <[EMAIL PROTECTED]> writes:
Joshua> PERL might be a good choice for the RCS-translator that
Joshua> I'd like to write
Not to mention other languages that we haven't even mentioned here.
eg. C++, Ada, etc (the list goes on).
I think for The Hurd to achi
On Thu, Feb 08, 2001 at 10:15:59PM +0200, Eray Ozkural (exa) wrote:
> So, you're saying that a well optimized ORB can be just as good as MIG.
> That raises two other questions:
> 1) Is CORBA going to be as slow as MIG?
> 2) Is MIG slow enough?
Performance is not really the concern here, altho
On Thu, Feb 08, 2001 at 01:05:30PM -0800, Jeff Bailey wrote:
> On Thu, Feb 08, 2001 at 10:15:59PM +0200, Eray Ozkural (exa) wrote:
>
> > For instance, do you really need to write hurd servers in different languages?
> > How useful/suitable would a server written in "perl" be? These are the kind
>
Eray Ozkural (exa) writes:
> For instance, do you really need to write hurd servers in different languages?
> How useful/suitable would a server written in "perl" be?
Whell, I, for one, would love to see RMS's original projection that "Both C
and Lisp will be available as system programming lan
On Thu, Feb 08, 2001 at 10:15:59PM +0200, Eray Ozkural (exa) wrote:
> For instance, do you really need to write hurd servers in different languages?
> How useful/suitable would a server written in "perl" be? These are the kind
> of questions one should consider before writing a big amount of code
hi,
Igor Khavkine wrote:
>
> CORBA is only a source level standard. It is not restricted to IIOP
> or any other message passing protocol, the so to say "backend"
> can be changed according to need. For example regular IPC on the same
> machine can be done through the Mach message passing facilit
hi,
> CORBA is only a source level standard. It is not
> restricted to IIOP
> or any other message passing protocol, the so to say
> "backend"
> can be changed according to need. For example
> regular IPC on the same
> machine can be done through the Mach message passing
> facilities, like
> MIG
On Thu, Feb 08, 2001 at 11:34:26AM +0200, Eray Ozkural (exa) wrote:
> Mridul Jain wrote:
> >
> > hi,
> > As I was preparing to work on the topic - Corba
> > replacement for MIG ;
>
> Make sure it doesn't turn out to yield a Java level performance. ;)
>
> That standard called Corba was not tailo
hi,
> > I can notice the messages as they are being sent
> on this GNOME
> > desktop. That would not make a good bet for a hurd
> server.
>
> IMHO CORBA can be as fast as Mig, even faster.
>
yes I agree that IPC is faster than vanilla IIOP.But
there are ways by which we can increase the
perform
On Thu, Feb 08, 2001 at 11:34:26AM +0200, Eray Ozkural (exa) wrote:
> That standard called Corba was not tailored for microkernel
> message passing.
>
> I can notice the messages as they are being sent on this GNOME
> desktop. That would not make a good bet for a hurd server.
IMHO CORBA can be a
Mridul Jain wrote:
>
> hi,
> As I was preparing to work on the topic - Corba
> replacement for MIG ;
Make sure it doesn't turn out to yield a Java level performance. ;)
That standard called Corba was not tailored for microkernel
message passing.
I can notice the messages as they are being sent
Hi,
> As far as I know MIG only supports C. Modifying MIG
> to support other
> languages would probably not be worth the effort.
> Even the C code
> that it generates isn't that great either.
Yes that effort is not worth it!!!
> The more obscure featres of MIG support the more
> obscure featu
On Thu, Feb 08, 2001 at 09:14:57AM +1100, Brian May wrote:
> > "Mridul" == Mridul Jain <[EMAIL PROTECTED]> writes:
[snip]
> Mridul> protocol is that It is the Corba standard.If I want a
> Mridul> "TRUE" Corba implementation in GNUMach/HURD then the
> Mridul> protocol should be II
On Wed, 10 May 2000, Martin v. Loewis wrote:
> No, you are right. DII and DSI and part of the standard. They are just
> not very useful, except for very specialized applications. Instead of
> the DII and the DSI, those applications could use an internal API of
> the ORB as well - for example, peo
Date: Tue, 9 May 2000 22:55:21 +0500 (GMT-5)
From: Sergey Izvoztchikov <[EMAIL PROTECTED]>
On Wed, 10 May 2000, Mark Kettenis wrote:
> Indeed. I don't really have experience with CORBA, but I don't think
> the issues in this thread are relevant in this stage of Hurd
> developm
> As I understand ORBit is going to have DII, DSI in near feature.
> And I think that DII and DSI supposed to be in ORB. Correct me
> if I'm wrong.
No, you are right. DII and DSI and part of the standard. They are just
not very useful, except for very specialized applications. Instead of
the DII
On Tue, 9 May 2000, Martin v. Loewis wrote:
> > That's right. But It seems as a completely new environment for me and
> > it has less conformance even that ORBit.
> I won't argue about the "new environment" part. On the "less
> conformance" part, can you give me a feature that is implemented
>
On Wed, 10 May 2000, Mark Kettenis wrote:
> Indeed. I don't really have experience with CORBA, but I don't think
> the issues in this thread are relevant in this stage of Hurd
> development. Right now the core Hurd protocols are defined by the MiG
> .defs files. At one side this defines the C
If you don't like the corba->c idl mapping, bad luck, the servers are
implemented in C. However shifting to CORBA is nice as it opens the
possibility of C++ hurd servers. However there may be other reasons that C++
can't be used (I am not familiar w/implementation details of hurd servers).
If a c+
Date: Tue, 09 May 2000 13:09:59 -0400
From: Serguei Izvoztchikov <[EMAIL PROTECTED]>
Jeff Bailey wrote:
> I'm not a Master-Hurd-Programmer, but I know that Roland and Thomas have
> declined to add wrappers within their header files to permit linking from
> C++ programs, so I do
Date: Tue, 9 May 2000 23:28:58 +0200
From: "Martin v. Loewis" <[EMAIL PROTECTED]>
[ This is not really directed to you Martin, but the last line of this
message just provided a convenient point to jump in the discussion. ]
> > No, it isn't. Its license is more liberal than the GPL.
> I just want to start with most conformant ORB. I suppose CORBA
> developers may need these parts.
A check-box point of view may not give you a correct answer to the
question "what ORB is most conformant". You'd also had to consider
correctness of the implementation. Also, there are other typica
"Martin v. Loewis" wrote:
> That is all still correct. However, instead of the BOA, ORBit supports
> the POA. Why do you need the DII, DSI, or IFR?
I just want to start with most conformant ORB. I suppose CORBA
developers may need these
parts.
> > To be clear. Is ILU GPL'ed ? I don't think so.
>
> I know that ORBit is used in GNOME, but according this page
> - http://www.vex.net/~ben/corba/orbmatrix.html
> ORBit lacks DII, DSI, IFR, BOA. Probably information on page is out of
> date.
That is all still correct. However, instead of the BOA, ORBit supports
the POA. Why do you need the DII,
"Martin v. Loewis" wrote:
> Hmm. If you want to use C, you'll have to use the C mapping, whether
> you like it or not (you could define an alternative C mapping, but it
> would not be much simpler). If you don't want to use the C mapping,
Agreed.
> what is then the problem with using C++?
I know
"Martin v. Loewis" wrote:
> I think both parts of that statement are incorrect. ORBit is not in
> early development; instead, it is a mature implementation which has
> been extensively tested as part of the Gnome project.
I know that ORBit is used in GNOME, but according this page
- http://www.ve
> I know this. It just has lack of basic CORBA services yet. I'm sure
> it will go well and have them latter, but now MICO/OmniORB2 support
> CORBA standard better.
Out of curiosity: Which of the "basic CORBA services" do you need that
are still missing, and what do you need them for?
> And seco
> Only one GPL ORB with C mapping is ORBit, which is still on early
> development stage.
I think both parts of that statement are incorrect. ORBit is not in
early development; instead, it is a mature implementation which has
been extensively tested as part of the Gnome project.
Furthermore, ther
Jeff Bailey wrote:
> I'm not a Master-Hurd-Programmer, but I know that Roland and Thomas have
> declined to add wrappers within their header files to permit linking from
> C++ programs, so I don't think they're going to change.
What is the reason ?
--
Best regards.
Sergey Izvoztchikov.
mailto
On Tue, May 09, 2000 at 11:54:57AM -0400, Serguei Izvoztchikov wrote:
> I know that most of Mach/Hurd servers were written in C,
> may be it's time to change this ?
I'm not a Master-Hurd-Programmer, but I know that Roland and Thomas have
declined to add wrappers within their header files to per
Jeff Bailey wrote:
> On Tue, May 09, 2000 at 09:59:02AM -0400, Serguei Izvoztchikov wrote:
> > Only one
> > GPL ORB with C mapping is ORBit, which is still on early development
> > stage.
>
> ORBit is the main ORB for GNOME, IIRC. You may want to use that, since
> it will probably be loaded on
On Tue, May 09, 2000 at 09:59:02AM -0400, Serguei Izvoztchikov wrote:
> Only one
> GPL ORB with C mapping is ORBit, which is still on early development
> stage.
ORBit is the main ORB for GNOME, IIRC. You may want to use that, since
it will probably be loaded on most Hurd systems once X is runn
54 matches
Mail list logo
