Announcement
Collapse
No announcement yet.
Will Mir Come On The Ubuntu 14.04 Desktop?
Collapse
X
-
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.
Comment
-
-
Originally posted by LinuxGamer View Postthe 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
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.
Comment
-
Originally posted by mrugiero View PostYes, and you can use arrays in C++. You can also avoid this kind of problems in C, through accessing with macros.Last edited by JS987; 20 October 2013, 12:16 PM.
Comment
-
Originally posted by JS987 View PostC 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.
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.
Comment
-
Originally posted by mrugiero View PostI 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.
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++).
Comment
-
Originally posted by ciplogic View PostAt 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++).
Comment
-
Originally posted by mrugiero View Post(...)What I meant was obviously that your real kernel will be the one who deals with the hardware, not that everything else loses sense.
Originally posted by mrugiero View PostIt 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.
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?
Comment
Comment