Will Mir Come On The Ubuntu 14.04 Desktop?

[uid313]

the main thing i think is C is more lean than C++ also you can do most any thing in C as C++ for development like a kernel to me C and C++ suck and C# sucks evem more do to it being a microsoft toy

There are actually kernels and operating systems coded in C#.
Such as Singularity, SharpOS, Cosmos.
As well as other managed code operating systems written in Java and other languages such as JavaOS, JNode, and JX.

[mrugiero]

There are actually kernels and operating systems coded in C#.
Such as Singularity, SharpOS, Cosmos.
As well as other managed code operating systems written in Java and other languages such as JavaOS, JNode, and JX.

I didn't check the java ones, but IIRC all of them have a basic C core, since the managed platform needs a VM to run, and this one needs to directly talk to hardware. You know, because you eventually need to talk to hardware to run a computer.
EDIT: Also, I thought I was clear in what I meant. I didn't mean the syntax wasn't that of C#, I meant you would be essentially doing the same unsafe things you do with C, which is basically talking to hardware.

[mrugiero]

Arrays which support out-of-bounds access are unnecessary and dangerous, when code isn't properly checked which is common problem.

Yes, and you can use arrays in C++. You can also avoid this kind of problems in C, through accessing with macros.

[Pajn]

the main thing i think is C is more lean than C++ also you can do most any thing in C as C++ for development like a kernel to me C and C++ suck and C# sucks evem more do to it being a microsoft toy

And why does you think C++ sucks? Because you doesn't know what it is?
Well, it's like C but with Object Orientation (well that's the main thing at least).

C# have very little to do with C and C++ as far as the kernel is concerned.
C and C++ compiles to native binaries while C# (like Java) compiles to a "middle code"
that's compiled to native binaries when runned, big difference.

[JS987]

Yes, and you can use arrays in C++. You can also avoid this kind of problems in C, through accessing with macros.

C arrays are supported also in C++ because of backward compatibility. In C++, array access checking can be enforced with templates. It is important that language should be safe by default when possible, which means users won't suffer because of incompetent developers.

[mrugiero]

C arrays are supported also in C++ because of backward compatibility. In C++, array access checking can be enforced with templates. It is important that language should be safe by default when possible, which means users won't suffer because of incompetent developers.

And in C it can be enforced with macros.
On the other hand, I'm not denying that C++ could be better. I am aware the fact it's the most used language in kernels have more to do with the fact it already was a long time ago than with any capability of C (probably before C++ compilers were good enough, and before the most used standards existed), and rewriting is undesirable in some cases.

[ciplogic]

I didn't check the java ones, but IIRC all of them have a basic C core, since the managed platform needs a VM to run, and this one needs to directly talk to hardware. You know, because you eventually need to talk to hardware to run a computer.
EDIT: Also, I thought I was clear in what I meant. I didn't mean the syntax wasn't that of C#, I meant you would be essentially doing the same unsafe things you do with C, which is basically talking to hardware.

So here you're wrong. Singularity has a "C# core" if you mean this, and to achieve this they use this compiler. I am also working to a compiler that can take MSIL and rewrite it into "raw C++" - which is at the abstraction level of C, but uses some convenience constructs of C++ (mostly the smartpointers and the "inline in headers" part), so I know that is possible to be done at the lowlevel. If you ask about in which language is written my virtual machine, is C# (it is a virtual machine at all levels, because it reads the bytecodes and eventually abstracts the machine).

But even it would not be possible, your argument will be still weak, isn't it so? All C or C++ kernels may depend at times of some assembly. Does this make FreeBSD or Linux an "assembly written kernel"? And Windows kernel it is known to use C++ (to some extent, it uses more after Win8 release), some C and some assembly, but still doesn't make either of those to say: all kernels are written in "assembly", whatever what it means.

At last, even the kernels would not be possible to be written in C++, or in CIL or in Java bytecodes, why would it matter for Mir? Maybe Mir will include a VM like NetBSD includes a Lua interpreter, to configure it, so tools that configure multi-screen setups will use Lua to quickly setup the screen and to not work with "XRand" extension to do so.

For "controversy" I will say that Mir will include a Mono VM, what posibilities (potential benefits) would it bring for "masses":
- it would be possible to configure Mir using a web page (using XSP)
- it would be possible to expose web services, to use remoting to work with some internals of the Mir components
- it would be possible to expose some OpenCL capabilities of the machine and to be tested using reflection
- it would be possible to run multithreaded state machines in animation frameworks as part of the display manager
Sure, Mono runtime overhead means a lot on mobile devices, but also it doesn't mean that just because it runs a VM means nothing because "the core is still C", and exactly for Mir case, C++ can give a lot of benefits (including maybe the skillset of the Mir developers that may be grounded in C++).

[mrugiero]

At last, even the kernels would not be possible to be written in C++, or in CIL or in Java bytecodes, why would it matter for Mir? Maybe Mir will include a VM like NetBSD includes a Lua interpreter, to configure it, so tools that configure multi-screen setups will use Lua to quickly setup the screen and to not work with "XRand" extension to do so.

Actually, I wasn't relating it to using it to Mir, but following the off topic conversation. As I said, I don't consider the language choice to be inherently bad, anyway.

For "controversy" I will say that Mir will include a Mono VM, what posibilities (potential benefits) would it bring for "masses":
- it would be possible to configure Mir using a web page (using XSP)
- it would be possible to expose web services, to use remoting to work with some internals of the Mir components
- it would be possible to expose some OpenCL capabilities of the machine and to be tested using reflection
- it would be possible to run multithreaded state machines in animation frameworks as part of the display manager
Sure, Mono runtime overhead means a lot on mobile devices, but also it doesn't mean that just because it runs a VM means nothing because "the core is still C", and exactly for Mir case, C++ can give a lot of benefits (including maybe the skillset of the Mir developers that may be grounded in C++).

I don't really get your point here. What I meant was obviously that your real kernel will be the one who deals with the hardware, not that everything else loses sense. It would be a micro kernel that interfaces the servers through a VM, but the real kernel and drivers will need to face the fact they are talking with real hardware. The kernel is usually considered the part that talks to hardware, and that, by definition, can not be abstracted by a VM.

[ciplogic]

(...)What I meant was obviously that your real kernel will be the one who deals with the hardware, not that everything else loses sense.

A VM can talk with the hardware, if a small bootstrap is written on bottom, isn't it? You just need some primitives in the VM (and most VMs give the chance to write this primitives in the language of your choice). But bootstrapping doesn't make the kernel to not be written in the main language, whatever this language/VM would be. I can compare the BeOS microkernel which was written in C++, and it has multiple servers that were written in C++ and they have a lightweight API (written in C and some assembly) to communicate in between servers.

It would be a micro kernel that interfaces the servers through a VM, but the real kernel and drivers will need to face the fact they are talking with real hardware. The kernel is usually considered the part that talks to hardware, and that, by definition, can not be abstracted by a VM.

But most VMs (that do not have interpreters) talk directly with hardware. They generate JIT compiled code which is by definition directly to hardware (as is outputted binary in-memory executable code). Ahead of time compilers (as Bartok, GCJ or Excelsior Jet, or Mono AOT) that do execute VM bytecodes are generating a code that directly runs on hardware, isn't it so?

Having a bootstrapped assembly/C and on top there is a small VM wrapper and all drivers, schedulers and low level processes are written in MSIL(even this MSIL is later recompiled in binary executable), doesn't make for me to say that the kernel is assembly. If itself it integrates a compiler service as part of kernel that brings with it other components (like described earlier) that can be itself written in C# with some small assembly backend, still makes the kernel written in assembly, isn't it so?

[mrugiero]

I won't quote because your post is too long for the short answer you'll get. But I think I get your point, now, and I think you are right, ciplogic.