Announcement

Collapse
No announcement yet.

The DDE 2.0 Desktop Is Looking Nice

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

  • #11
    Originally posted by Bestia View Post
    Yes you must be either looking in wrong place or your searching sucks.

    https://github.com/linuxdeepin
    I looked at: http://www.linuxdeepin.com/index.en.html. No link there. http://www.linuxdeepin.com/download.en.html -- no link there. Google for "site:www.linuxdeepin.com source code" -- no links to source code. A search for "deepin desktop project" leads me to sourceforge: http://sourceforge.net/projects/deepin/ -- where there is no source code. In fact, the first three page of that don't have any link to something with source code. http://planet.linuxdeepin.com only links to that github repo from an old translation article.

    Yes, I guess that "my searching sucks", and thank you very much for the compliment, but Deepin sucks at making their source code location visible.

    And even with your hint, I cannot find their release tarballs...

    Comment


    • #12
      how odd...

      Originally posted by Alliancemd View Post
      You can feel it that it uses web technologies... A few seconds delay after every click(the Control Center for example, first loads) is getting very-very irritating...
      It is certainly odd that you should be able to feel the web technologies... The control center code on github ( https://github.com/linuxdeepin/dde-control-center ) is written in Python, Qt5 and QML.

      Comment


      • #13
        Originally posted by widardd View Post
        Please explain in detail how my eeepc 901 is able to achieve a comparable responsiveness to LXDE+Openbox using a DE consisting of HTML5 and JS.
        It will take some time but if you look at academic conferenses about programming languages and the hype in general, most effort goes into dynamic languages and especially JS. No doubt JS is now a bit slower still, but in the future it will have fastest VM, fastest FFI and interface with GPU, asm.js like accelerations. It will quickly replace all other scripting languages by an order of magnitude better performance. It's also possible to write slow C/C++ if you're a novice. So.. for a casual user the JS will turn out to be faster way to do things. It also encourages more voluntary workers since the language is easier to approach. Computers will also become faster so it doesn't matter if JS won't become lightning fast. You can't buy the slow computers soon anymore. Only 2.0 GHz ARM, Core i3 x86 at minimum, no slower machines.

        Comment


        • #14
          Originally posted by caligula View Post
          You can't buy the slow computers soon anymore.
          Sorry, but i got a serious problem with attitudes like this.
          Forcing users to buy new products every 5 years is wasting ressources.
          And wasting ressources just because they're cheap (Memory for google/MS/KDE/GNOME) is the worst.

          Anything not "close to metal" is wasting ressources, if you ask me. How can concentrating everything on unefficient high level languages be a good idea regarding this?

          As long as i see JS locking up my 5-6 year old machines, or an ARMv6 with Maemo surpassing modern day Snapdragons with Googles funny VM, i don't think i can be convinced.

          Comment


          • #15
            Originally posted by caligula View Post
            You can't buy the slow computers soon anymore. Only 2.0 GHz ARM, Core i3 x86 at minimum, no slower machines.
            You can buy computer with small memory since 16 GB RAM became expensive. ARM is much slower than Core i3.

            Comment


            • #16
              Originally posted by caligula View Post
              It will take some time but if you look at academic conferenses about programming languages and the hype in general, most effort goes into dynamic languages and especially JS. No doubt JS is now a bit slower still, but in the future it will have fastest VM, fastest FFI and interface with GPU, asm.js like accelerations. It will quickly replace all other scripting languages by an order of magnitude better performance. It's also possible to write slow C/C++ if you're a novice. So.. for a casual user the JS will turn out to be faster way to do things. It also encourages more voluntary workers since the language is easier to approach. Computers will also become faster so it doesn't matter if JS won't become lightning fast. You can't buy the slow computers soon anymore. Only 2.0 GHz ARM, Core i3 x86 at minimum, no slower machines.
              JavaScript is about 10x harder to program than C, is an awful, completely crippled language and is slow as shyt.

              It doesn't surprise me that everyone thinks it's the wave of the future.

              Comment


              • #17
                This is why web developers are not suited to write software. Any decent programmer knows HTML and JS can never achieve the required level of responsiveness. It's not a matter of optimizing, but rather the fundamental implementation. In order to achieve responsiveness you need complete control of threading, timing, callbacks and execution time, JS will never be able to do this.

                JS is not only slower, it's also way harder to debug. Compiled code will always retain the advantage of predictable execution.

                Comment


                • #18
                  Originally posted by caligula View Post
                  Only 2.0 GHz ARM, Core i3 x86 at minimum, no slower machines.
                  My raspberry says "fuck you"

                  Comment


                  • #19
                    Originally posted by doom_Oo7 View Post
                    My raspberry says "fuck you"
                    It's a toy. Back when RPI was published dual or quad-core Cortex-A9 1.2 GHz ARM was pretty normal for dev boards. RPI is 50% slower clock per clock. That means 8 times slower.

                    Comment


                    • #20
                      Originally posted by caligula View Post
                      RPI is 50% slower clock per clock. That means 8 times slower.
                      CPU scaling doesn't work that way, you cannot simply abstract performance from 1 to X cores.

                      Comment

                      Working...
                      X