Announcement

Collapse
No announcement yet.

Lots Of Ubuntu Mir Changes Expected Next Week

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    Originally posted by erendorn View Post
    The kernel manages its own memory. It is an incredible headache in a kernel code if your compiler does too many things automatically between your source code and the object code, which a C++ compiler does. Most kernels, including windows ones, are in C for that reason.

    Wayland is nowhere near that low (unless I am mistaken, everything happen in user space).
    You are right. Wayland is not really low level when you compare it to the level of the Kernel.

    Comment


    • #62
      Oh Hai, I saw your flamewar and thought I'd fan the flames a bit...

      Comment


      • #63
        Originally posted by jayrulez View Post
        It is your lack of knowledge about that topic that leads to that conclusion. The year is 2013, not a point in the 90s.
        well this is very relative, i mean wayland itself is very low not as low as kernel tho but very very close.

        Remember the concept of low level programming is not related on how close or far is to the kernel but how close to the actual hardware you have to operate.

        In the case of Wayland you have to manage memory allocations and buffering[SHM/EGL/Others] and it interacts very closely with KMS/DRM/ioctls/syscalls/etc which are kernel elements, you have to handle elements of IPC directly from input devices through EVDEV, etc. So certainly C++ is possible but since everything around wayland is very close to the hardware and is in C already, C is a very good design choice here that allow you fine tune and go as close to hardware/kernel as possible when needed and you save a lot of
        Code:
        extern "C"
        calls and hacks when dealing with specilized buffering and allocation.

        now to interact with wayland and superior i consider C++ a better option since the closer you get to GUI level OOB programming is more efficient and less complicated given is done right of course.

        My point in resume is use the right tool for the job, for example

        * need to manage kernel data or memory specialization make a C library to use from C++
        * need to implement logic/gui use c++ and call your C library for lowlevel operations
        * need GUI design QML or related no need to use a nuke against an ant
        * need small object or widgets for the user to interact with small data, use python/perl/ruby/etc the performance penalty is neglible and will save lots of your hair

        thereis no such thing as perfect language for every possible situation, just good tools for each level and the trick is learn to use them effectively

        Comment


        • #64
          Originally posted by dee. View Post
          Oh Hai, I saw your flamewar and thought I'd fan the flames a bit...

          http://www.yosefk.com/c++fqa/
          well is a bit extreme but could be a good guide about what not to do in C++, well one thing is true tho C++ in hands of a bad developer can be horrible and more more visual than C since the flexibility of C++ works against it ironically but well used can be beatiful

          Comment


          • #65
            Originally posted by jrch2k8 View Post
            well is a bit extreme but could be a good guide about what not to do in C++, well one thing is true tho C++ in hands of a bad developer can be horrible and more more visual than C since the flexibility of C++ works against it ironically but well used can be beatiful
            Example of C++ well used: https://github.com/genodelabs/genode

            Comment


            • #66
              Originally posted by erendorn View Post
              You really have no clue, do you? How will client side support for application (QMir or any other) help a DE in making a shell, compositor and display server for Mir?
              Here the answer is simple Mir is a compositor and display server with an API, not a protocol like the wayland approach. It does not need each DE to write it's own compositor and display sever.

              Comment


              • #67
                People saying C++ is bad where C is good doesn't know what they are talking about.
                Good written C code are perfectly valid C++ code.

                People saying that a display server is vary low level close to the kernel are again
                not knowing what they talk about.

                The kernel basically only talks with the hardware. The display server does not
                talk with the hardware.

                The kernel have to handle itself, it have nothing but hardware under it, a
                display server get a lot of stuff free from the kernel and the graphic driver.

                A display server is closer to tool-kits like QT, GTK, Motif and whatever than
                to the kernel.

                Comment


                • #68
                  Originally posted by Pajn View Post
                  People saying C++ is bad where C is good doesn't know what they are talking about.
                  Good written C code are perfectly valid C++ code.
                  Well, last time I checked, C++ compilers kept complaining about using "deprecated functionality" when given well-written C code

                  Comment


                  • #69
                    Originally posted by Pajn View Post
                    People saying C++ is bad where C is good doesn't know what they are talking about.
                    Good written C code are perfectly valid C++ code.

                    People saying that a display server is vary low level close to the kernel are again
                    not knowing what they talk about.

                    The kernel basically only talks with the hardware. The display server does not
                    talk with the hardware.

                    The kernel have to handle itself, it have nothing but hardware under it, a
                    display server get a lot of stuff free from the kernel and the graphic driver.

                    A display server is closer to tool-kits like QT, GTK, Motif and whatever than
                    to the kernel.
                    1.) true
                    2.) this has more shade of gray than black or white
                    3.) kernel have many layers and only 1 of them talk to the hardware
                    4.) partially correct
                    5.) is exactly in the middle no more no less

                    to short answer 2,4, is true that an display servers don't query the graphic card / input directly in C/ASM/registers like a kernel module would do but is true also this module for many operations just pipe the raw hardware data to an upper layer as is also true you are still close enough to the hardware to need hardware/kernel layer compliant data structures. sure the kernels provide small layers in between to provide some normalization for know operations but even so is closer to kernel/hardware than to high level userspace

                    to explain 5, wayland and most display server have 2 faces which is why they are in the middle, the first face is hell lot closer to the kernel/hardware than any toolkit ever be and the other face is the definition of the user accesible API which abstract the whole lot of kernel/hardware operations to be used for toolkits that by definition of abstraction is very far from the kernel/hardware

                    Comment


                    • #70
                      Originally posted by allenmaher View Post
                      Here the answer is simple Mir is a compositor and display server with an API, not a protocol like the wayland approach. It does not need each DE to write it's own compositor and display sever.
                      Although this is technically true, many want one anyway, and in fact some cannot work without their own compositor, so trying to make these work with Mir's compositor would be a huge job.

                      Even if we grant your premise, however, DEs still need a stable API that is written to work with many DEs. Mir, on the other hand, pretty much guarantees an unstable API written to work with one and only one DE.

                      Comment

                      Working...
                      X