> > > Because Mono has to implement all these "system level" semantics that
> > > don't exist on unix, it has to create a sort of pseudo-system-wide layer
> > > itself. This means that all your Mono processes have to be able to talk
> > > to each other.
> > UNIX of course has no mechanism to allow programs to talk to each other. :(
> I of course meant they need to talk to each other surreptitiously,
> whether you want them to or not. Whether this is useful to your program
> or not.
I was being sarcastic.
> > > The way it does this is the first Mono prcess you launch is not really
> Sure, it's an okay design when done intentionally. But in this case,
> the spawned program that is your processes's direct child might be the
> program you wanted, or might be a handler daemon, depending upon whether
> there was one already running. It's a minor irritant having this be
> inconsistent like this.
That's just stupid.
It's no harder to write:
if((pid=fork()) != -1 && pid == 0) { spawn_handler_daemon(); }
Than to write:
if((pid=fork()) != -1 && pid != 0) { spawn_handler_daemon(); }
At this point I generally go charging in and start sending in code patches
but frankly Mono sounds like something that needs all the hindrance it
can get.
> > I am driven to ask, though, is this actually using $HOME or is it
> > calling getpwuid(getuid()) to find your home directory?
> I did not mean the env variable. I assume it uses the normal calls.
The env variable *is* the normal call. Only programs sitting at a trust
boundary and replicating the environment from scratch to prevent security
vulnerabilities should be using getpwuid(getuid()).
This would incidentally give you a back door solution to some of the
problems.
> Mono is somewhat sound in terms of technology, it just has completely
> stupid design.
I can't parse that sentence. Each part of it makes sense individually, but
put together the result is noise. What do you mean by a completely stupid
design being sound?
