On Monday 13 March 2006 17:10, Robert Schiele wrote:
On Mon, Mar 13, 2006 at 04:11:53PM -0500, Joseph M. Gaffney wrote:
And PE is used on 32 and 64 bit Windows. So what you're saying is, we're
And on any implementation of the CLI specification like Mono.
Correct me if I'm wrong... but don't you mean CLR spec, which satisfies the CIL requirement?
running a 32 or 64 bit Windows binary executable. Is that what is being said now?
We are running CIL byte code within Mono.
So whats being done with Zen is JIT compilation, am I correct here? My understanding of C# is that it always runs natively, whether compiled as native code, or CLR bytecodes (as mentioned) w/ JIT compilation. This is the source of my worry regarding cpu/mem usage.
My point remains (from the other trail of this thread) that a windows binary (which a PE would be, btw) has no place on Linux, for more reasons than
PE is just an extension of the COFF file format. The COFF file format and many other of it's extension are used on various UNIX flavours and other operating systems.
Extension... yes. The three E's come to mind on this one. Anywho... Modern *nix's, such as Linux, Solaris, Irix, BSD's (well - except OSX), etc, as you know use ELF, because COFF was far too limited. PE... still limited. It lacks good versioning, can cause a decent amount of pain with conflicts, overly complicated by comparison to ELF, not as easy to extend as ELF, doesn't contain ELF goodies like prelinking, symbol versioning, storing binaries within a PE is not possible while it is with ELF, the PE EULA has some built in legal concerns, and ELF is very well specified across many architectures. I take odds with alot of what Mono has to offer us - not in terms of, as I said, what can be offered to the corporate desktop, but what it does to us as opposed to for us on a regular, home/hobby user Linux machine. It just doesn't sit well with me.
Although I consider ELF to be superior to PE I can't see why PE "has no place on Linux". Linux used a.out prior to ELF which is a plain stupid format compared to PE.
Yes, though thankfully not anymore :)
.class is interpreted by the java vm, and ycp is handled by yast - so they aren't exactly the same type of situation. Unless you're saying its interpreted.
Sure it is --- or compiled by a just-in-time compiler, depending on the implementation of the runtime system. Thus it is exactly the same situation with the only difference that CIL is a more advanced language than Java bytecode or the ycp script language.
So is Zen a compiled binary, or is it still interpreted by Mono? If its a compiled binary, then I still don't get wtf Mono is needed for. If its being interpreted, wtf is interpreted code doing in a core application?
Huh? Even before this change YaST was already using YCP. Now there is a more advanced language used as well.
Are you comparing perl to java? C'mon.... maybe at the CLI there could be some basically similar performance, but not in any more complex environment.
Please excuse my laziness in not looking more closely at the files myself, I have a very hectic week, and my weekend (while spent out of the office) was all but useless as far as rest and hobbies go.
It's ok if you have no time to inform yourself about the basics but then it might be useful to take this into account when giving comments on a topic.
I meant I didn't have time to hack away at the file itself. The overall issues with Mono/.Net remain, regardless of my screwing around and seeing precisely what makes Zen tick. Its also why I've asked developers to respond as to what advantages Mono will be offering in this new package manager, that couldn't be done the same, and faster, in C++ or some such. Which is why in certain areas, I've asked, as opposed to reviewing the problem I have with it.
Robert
Joseph M. Gaffney aka CuCullin