Announcement

Collapse
No announcement yet.

Vote On A Distribution For Linux Benchmarking

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

  • Originally posted by grenadecx View Post
    I asked in what way was it not GNU/Linux.


    But yeah. I guess I'm just trolling.
    Have a good day.
    dunno what get you offended, the question "what way was it not GNU/Linux" made not sense to me[english is not my main language] so logically i proceed to read again the previous line " Ubuntu is just as much GNU/Linux as Debian, Fedora or any other distro out there." and concluded that "what way was it not GNU/Linux distro" since make more sense to me that way and since GNU/Linux is quite a general term i proceeded to discard it as a simple way to imply linux based distros and replied accordingly to that, specially since the context of the thread is under the "Desktop use" concept and go all the way down to glibc/gcc/GNU tools made even less sense to me

    second i wasn't replying to you this time but the others deliberatingly trying to skip some points and make it look like i said the GNU/Linux is not present in ubuntu or any other distro when my replies are based on the concept is "different from other distros" which in the "Desktop use" concept make no damn sense to go that low

    Comment


    • Originally posted by nll_a
      If the software uses Qt and EGL libraries, what could be the problem? We can only wait and see.
      well you won't find a huge wall like i said drawsquare and mir draw a circle[easy to solve] but more the little devilish issues, for example this will be a common cases to be considered.

      Case 1: ) with wayland is easy to get exclusive access to the GPU if your app is alone[xbmc/boxee/specialized/etc]without querying anything since you are the client/compositor/server all in one but Mir is a central process server and compositor, so through Mir API or Qt QPA queries you need to know Mir is active because hell could break loose if you try to composite inside your app because will collide with Mir compositor and will probably give weird render results, so probably have to inform Mir you wanna composite yourself or disable that feature and use built in composite operation existent in Mir

      Case 2: ) Wayland handle many form of buffer server and client side using software or hardware path and mixed, all with a variety of color initializations, so you must be careful to use buffers that both Mir and Wayland can understand or have specific buffering routines for each.

      Remember EGL is an API used by Mir/Wayland but is not part of the specification of either, is just good enough to be considered by both as default context initializacion API in linux/mobile, as quoted:

      "EGL is a window system-independent equivalent to the GLX and WGL APIs, which respectively enable OpenGL support in X and Microsoft Windows. It is an interface between Khronos rendering APIs such as OpenGL ES or OpenVG and the underlying native platform window system. It handles graphics context management, surface/buffer binding, and rendering synchronization and enables high-performance, accelerated, mixed-mode 2D and 3D rendering using other Khronos APIs." <-- named GLes/opengl/openvg/etc

      Sure most of this heavy lift will be done by toolkits but is true too that is really really common for developers to create custom widgets/render paths/components in their applications and for that you mostly have to leave the toolkit API and go to a lower more appropriate API and here is mostly where things can go south, for example Gis/map/cad/3D/Games/medicine/embedded/specialized Apps will more likely have to deal with wayland/mir/opengl/egl/gles/kernel/SDL APIs directly to squezee the performance and advanced techniques needed for this areas since no regular toolkit will provide premade widgets for them, just virtual classes for do it as you wish kinda fashion[<-- is the best way]

      so certainly won't affect most average mail/office/internet users but for more powerful apps can be very annoying for developers to deal with

      Comment


      • In fact with all the testing you do I would imagine you wold have to do a lot of clean installs to keep the data rational.

        Comment


        • not really, if you ever had to deal with multiple platforms in your apps this come quite as a rutine since this is done for every platform and needs to be done with X/tool kits today too, the only change is that you have 2 new APIs + old good X11 to take care instead of 1 new API and old good X11 for the simple fun of it.

          and those specifics i named happens too between releases of an already supported platform, is not exclusive of new display systems either and nor is linux exclusive since it needs to be done sometimes in windows[DX, D2D-GDI, etc. ] and Mac too[x11/quartz]. The trick is find the most common lower denominator between the both API or support both or support only one.

          Either way you don't need to uber analize both protocol code line by line since even if they are 99.99% identical and the only difference is something simplistic like Wayland render RGB textures in ascendant order and Mir do it in descendant[simply an example it does not relate to either code] you know hell can break loose anytime and you should start thinking in handling yourself the buffer order and convert it on demand depending the backend just to be sure it won't play hell with other parts of your code.

          again this prolly won't affect final users directly beyond crashes or weird render issue depending the backend but it sure will help your freindly neighbor geek go bald faster

          Comment


          • Originally posted by Vim_User View Post
            Fixed that for you.
            Not exactly, Debian is a slow moving ultra stable behemoth of a distribution(last I checked you had the option of an 11 DVD sized version lol).

            Ubuntu differentiates itself enough from Debian that it can be considered a true distro unlike the re-spins of it.

            Comment


            • Originally posted by Deb6orah View Post
              In fact with all the testing you do I would imagine you wold have to do a lot of clean installs to keep the data rational.
              Separate drives of the same exact model with a roll of tape and a marker?

              Comment


              • Originally posted by Kivada View Post
                Not exactly, Debian is a slow moving ultra stable behemoth of a distribution(last I checked you had the option of an 11 DVD sized version lol).

                Ubuntu differentiates itself enough from Debian that it can be considered a true distro unlike the re-spins of it.
                The poll mentions Debian Sid, not Debian Stable, not slow moving, not ultra-stable. How is the fact that you can download the entire repository of Debian as ISOs relevant? What besides a different desktop shell (and in the future Mir/XMir) is so relevant that you can't consider Ubuntu to be a Debian Sid (or Testing, in the case of LTS versions) respin?

                Comment


                • Originally posted by wizard69 View Post
                  I never really understood the fascination with Ubuntu. I alway saw it as a crap botch job of a distro.

                  Beyond that does it make a big difference. I mean really if you compile a new kernel for testing or new graphics drivers aren't you in the custom distro zone. In fact with all the testing you do I would imagine you wold have to do a lot of clean installs to keep the data rational.
                  Originally posted by Deb6orah View Post
                  In fact with all the testing you do I would imagine you wold have to do a lot of clean installs to keep the data rational.
                  Just sayin'...
                  Test signature

                  Comment


                  • Originally posted by nll_a
                    Yes it is, it's alpha Unity, and it doesn't matter one inch if they share the same codebase or not.
                    No, it does matter. Development starts when the first commit hits the repository, that's that simple. Everything before that is just planning and hypothesising.

                    Originally posted by bridgman View Post
                    Just sayin'...
                    Man, you're in the weirdest of threads sometimes But you probably shouldn't quote the images of spambots, because that way they can't be deleted in bot sweeps.

                    Comment


                    • Originally posted by jrch2k8 View Post
                      well you won't find a huge wall like i said drawsquare and mir draw a circle[easy to solve] but more the little devilish issues, for example this will be a common cases to be considered.

                      Case 1: ) with wayland is easy to get exclusive access to the GPU if your app is alone[xbmc/boxee/specialized/etc]without querying anything since you are the client/compositor/server all in one but Mir is a central process server and compositor, so through Mir API or Qt QPA queries you need to know Mir is active because hell could break loose if you try to composite inside your app because will collide with Mir compositor and will probably give weird render results, so probably have to inform Mir you wanna composite yourself or disable that feature and use built in composite operation existent in Mir

                      Case 2: ) Wayland handle many form of buffer server and client side using software or hardware path and mixed, all with a variety of color initializations, so you must be careful to use buffers that both Mir and Wayland can understand or have specific buffering routines for each.
                      This is about Wayland apps running on Mir, the question was about Mir apps running on wayland, which will not have this problem.

                      Comment

                      Working...
                      X