Announcement

Collapse
No announcement yet.

GNOME 3 Might Be Too Resource Hungry To Ever Run Nicely On The Raspberry Pi

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

  • Originally posted by cynical View Post
    I don't believe you code. By what standard are you saying C is a 'proper' language compared to JS? The language was brilliant for its time, but broken by modern standards in significant ways. Lua and JS are very similar, other than the fact that JS has a much more comprehensive ecosystem, so your rant doesn't make any sense.
    Lua is lightweight, JS is not. I don't care about the language itself, it's all about the framework / implementation. Lightweight means Kilobytes, not MBs, btw. On an unrelated note, I always laugh when I see people toss their 10 MB+ application as "lightweight", wtf really guys? I don't think some people understand the words they are using.

    How is C lacking? C is by far the most powerful language (C++ can also be, though) because you can code almost anything with it. I mean, wait, we ARE talking about the quality of the END PRODUCT are we not? You know, the whole article is about resource hungriness of the end product, not "programmer convenience" or whatever other reasons are always parroted about the "shiny new languages".

    Because you know, real programmers code for the quality of their product, because end users don't give a shit how "maintainable" something is for monkeys, but if the application offers NOTHING of value compared to another and yet uses 10 times more RAM and is slow as piss, they know it's garbage. What is the point of having 10 times more products because of "accessible languages" for non-real programmers, all being bloated, instead of 1 quality product that is 10 times leaner where they could contribute to in a proper language like C? That's what I meant with 90% of products dying off. It's all about quality over quantity.

    And I'm not even close to being as pedantic as Linus in respect to trashing "modern languages", he even hates C++, which I don't (except the over-use of the standard library, GCC for example has pretty decent C++ usage, which is more like C in usage).


    Do you know why C doesn't evolve much? Because it's a stable, well-designed language that only needs a few new features once a decade or so. Yeah, there are some things it lacks, mostly compile-time capabilities (which C++ has an abundance of), but those are just for convenience. They won't optimize the code better or enable a leaner end product, since you can do those with scripting languages.

    Yes, scripting languages have their uses, such as in production or compilations or whatever. But deploying them? Most users will never touch them, what a waste really. Unless your target audience is supposed to script their own stuff, of course. I'm sure the average GNOME user cares so much about scripting in JS.


    tl;dr It's better to have 1 lean and super optimized project doing one thing and doing it right, than 10 of them with 9 being extremely bloated compared to how they should be. Imagine if someone wrote basic UNIX utilities like 'cat' in a scripting language, would you use it, what is the point of it when you have 'cat' written in C?!??

    Yes it's harder and slower to code in C, that's why it's quality over quantity. If people didn't waste their time with their fragmentation and redundant projects but instead learned how to code and contributed to pure C code, it wouldn't really be any slower in the end.
    Last edited by Weasel; 03 June 2018, 08:24 AM.

    Comment


    • Originally posted by Candy View Post

      Weasel is right by saying that a Desktop should be written in a proper language like C. With C you can get the most out of the hardware and even ensure that your code works more or less fluent on less powered machines. This can only be achieved with using C. For the Assembly part I agree! No one should be using Assembly anymore. I speak about own experience here - by having programmed 68000 Assembly for more than a decade.
      The core Gnome parts that require it are written in C. I'm not bashing C, it is what it is, which is one of the most popular system programming languages out there. But writing everything in C even when it isn't necessary for performance just slows down development. Have you tried the Gnome Weather app? If not, give it a shot. It's written in JS and is quite a nice app. Not everything needs to be able to run on a raspberry pi.

      Comment


      • Originally posted by Weasel View Post
        Lua is lightweight, JS is not. I don't care about the language itself, it's all about the framework / implementation. Lightweight means Kilobytes, not MBs, btw. On an unrelated note, I always laugh when I see people toss their 10 MB+ application as "lightweight", wtf really guys? I don't think some people understand the words they are using.
        Lua is compiled, JS is not. This gives JS many advantages in terms of being more flexible. If you don't think 10MB applications are lightweight, then I think I understand your perspective. Essentially, you just want the smallest / best performance possible no matter what else. I can respect that from a user's perspective, but consider that development time and having people even be able to contribute to a project is important too. (how many experienced Lua developers are there relative to JS devs?)

        Originally posted by Weasel View Post
        How is C lacking? C is by far the most powerful language (C++ can also be, though) because you can code almost anything with it. I mean, wait, we ARE talking about the quality of the END PRODUCT are we not? You know, the whole article is about resource hungriness of the end product, not "programmer convenience" or whatever other reasons are always parroted about the "shiny new languages".
        You can also break things very easily. There's array decay, null-terminated strings, lack of type safety (if you do any type casting, which people do), the variable size of int/char, the failure that is the switch statement (although JS has the same problem, for compatibility reasons I suppose :P). The problem with C that the new shiny languages don't have is that a lot of the complexity leads to brittle code. You get the best performance, but you need to be a lot more defensive and careful in exchange. The reason Gnome 3 takes more memory is not JS-related anyway. All DEs take more memory than they used to, and that's not automatically a bad thing.

        Have you ever loaded KDE and Gnome in a VM to compare them? At first I was impressed by KDE's lower memory usage, but then I loaded up some apps and especially a browser, and noticed almost no difference between them. Desktop environments are no longer the biggest memory hogs now that you have multi-process browsers running complicated web apps and many applications themselves using browser engines as their base for portability reasons.

        Ever run Slack? It uses as much memory as Gnome Shell or Nautilus, but it will run on any platform with ease.

        Originally posted by Weasel View Post
        Yes, scripting languages have their uses, such as in production or compilations or whatever. But deploying them? Most users will never touch them, what a waste really. Unless your target audience is supposed to script their own stuff, of course. I'm sure the average GNOME user cares so much about scripting in JS.
        Well I use Gnome as my DE, and I love the extensions people have written. And there are a number of apps written in gjs that are quite nice, like Polari for example. If you required everyone to use C to contribute, you would simply have fewer contributions.

        Comment


        • Originally posted by cynical View Post
          The core Gnome parts that require it are written in C.
          I am quite familar with the Gnome eco-system.

          Originally posted by cynical View Post
          Have you tried the Gnome Weather app?
          No thanks!

          Comment


          • Originally posted by Candy View Post

            Weasel is right by saying that a Desktop should be written in a proper language like C. With C you can get the most out of the hardware and even ensure that your code works more or less fluent on less powered machines. This can only be achieved with using C. For the Assembly part I agree! No one should be using Assembly anymore. I speak about own experience here - by having programmed 68000 Assembly for more than a decade.

            C is also not broken by definition. Broken are the programmers that lack knowledge about proper programming skills. People that have never programmed to save clock cyclles, ram, space, performance and speed. Of course these things doesn't need to be driven religious here, but performance still matters.

            Rather than speaking about optimizing code, these "so called developers" nowadays say "hardware is cheap", "harddisk space is cheap" as an excuse for their bad coding capabilities.

            And clearly JS does not belong into a Desktop shell!. For what ? Eating up all resources ? To use JS to code a few extensions (which says that there is a problem with the overall functionality of the shell per se) ? Or to make the entire desktop crawl like hell ?

            Compare Gnome3 with e.g. AROS or MorphOS. Both systems are entirely written in C., They boot up within seconds (a blink with the eye) on ancient rotten hardware. Clicking on an Icon to launch the program is another blink with the eye and the software is loaded up.
            No, I think you are in wrong way. If a DE whatever it's GNOME, KDE use frequently to much CPU, RAM, disk space, GPU and so on this mean something inside it's broken by design at the core level(or the application do not have (as a good general practice) a good builtin protection against crashes, errors, and that application should signal/report to user, that something is wrong and should fill a bug report, but not to crash unexpectedly or hang mysteriously(from user user perspective) at certain times moments or randomly) .

            And is the job of GNOME/KDE to correct these anomalies, and it's not a simple bug/task of a single user/developer, nor JavaScript fault since don't use some kind of web app built for desktop (let's say like Skype) on top of electron framework or something, but much simpler, only c libs+ JavaScript binding. Overall impact of JS code can't be that big. KDE use QML which is ECMAScript compatible and it's used for display GUI for commands of oceanic ships (or something like that). Qt/QML is significantly faster that JS/HTML5 equivalent for building performance user interfaces. As a demo:


            Best you (you meaning the Linux Distribution) can do, is to train average user to help package maintainer and application developer, on mainstream, to send useful bug reports and to install required infrastructure and so on.

            Firefox already has integrated a service, called telemetry that send anonymous data collected from browsing habits and should catch even bottlenecks.Simply removing JS is not a solution, even MacOS can be scripted using JavaScript.

            Telemetry

            It's helpful for Mozilla's engineers and decision-makers to be able to measure how Firefox behaves in the real world. The Telemetry feature provides this capability by sending performance and usage info to Mozilla. As you use Firefox, Telemetry measures and collects non-personal information, such as performance, hardware, usage and customizations. It then sends this information to Mozilla on a daily basis and we use it to improve Firefox.

            Comment


            • Originally posted by onicsis View Post
              As a demo:
              Ok this clearly did impress me.

              I've done a lot of programming in the past couple of decades. Assembler (hardware and system programming), C (same as asm), Pascal, Visual Basic, Java, HTML and a bit of JS using different types of toolkits like Motif, GTK, Gadtools (Amiga), MUI (Amiga), Swing, SWT and so on. But none of them comes close to what is shown in this video (about rapid development). That guy talked and basicly nailed a running flickr feed reader and image viewer within 15 minutes.

              Of course everthing behind the scenes are covered by the QML (was it QML) stuff that actually does the work. You don't need to worry about allocating memory, cumbersome declaring of buttons, open streams, close streams, open files and close files etc... But then I never used that stuff, so I can't comment any further But quite impressive.

              Originally posted by onicsis View Post
              Best you (you meaning the Linux Distribution) can do, is to train average user to help package maintainer and application developer, on mainstream, to send useful bug reports and to install required infrastructure and so on.
              The thing with distributions (llike Fedora) is, that they ship generic pre-made iso images to the audience. The workstation iso image for example loads a lot of stuff during boot up. e.g. httpd, starts an initial run of packagekitd, starts an initial run of dnf to make a cache (downloading metadata), starts a firewall service, starts tracker and so on.

              All this stuff (that also runs in the background) eats up memory, needs to be loaded, does some tasks and contributes to the overall experience of the distribiution. My sisters machine used close to 2 minutes to boot into GDM. Once inside the shell tracker continues its job indexing everything. You can basicly wait until everything is finished (and the harddisk LED is turned off) before proceeding with the work. I had to remove quite some junk to make the machine boot in 38 seconds into Gnome3.

              But the overall experience with Gnome3 is everything else than snappy. Flickering mouse. Sometimes when you move the mouse to the top left corner the shell goes into expose or does nothing, you move the mouse away, go into the left corner again, go away again and you see it basicly expose'ing, back to normal, expose'ing, back to normal etc. with a time lag of a few seconds.

              As an example: I have an own compiled Xfce4 running on Fedora (the version that becomes 4.14 soon) and this one uses around 10 seconds to boot after grub2 counted from 5 seconds to 0. The entire Xfce4 version uses Gtk3 (without an exception) and runs smooth, fluent, performant, fast... With a few exceptions like slow Gtk filechooser popping up and random black squares before popups pop up.

              This of course leads to the valid question where the bottlenecks are, if we compare Xfce4 with Gtk3 support vs Gnome3 (maybe shell) with Gtk3 support and what makes Gnome3 feels so sluggish slow.

              So yes! There are some conceptional or architectual bottlenecks - whatever they are - that needs to be solved. But then, I left the Gnome wagoon with the introduction of the shell. I am a happy camper with Xfce4 now and I don't think that I want anything Gnome3 related running on my system.

              As said: It's easy to blame everything on Gnome3 and the crawling shell but you can also blame the distributions for starting all kind of services in their default setup (because they don't know what the end-user really needs and wants - so they offer a wide range of options on the fly).

              There is even more: Compile flags used (if you compare the regular performance comparisons that pop up on Phoronics e.g. Clear Linux vs. rest of the world). This of course has also a big impact of performance.

              It's difficult...

              Comment


              • The only valid measurement of code quality: WTFs/minute

                Comment


                • Originally posted by leipero View Post

                  Well, whole premise of assuming gender and sexuality is based on what he meant, if he assumes "people who never saw p.. in their life", he clearly means on heterosexual males or homosexual females, there's no other option there = therefore, he assumed gender and sexuality.
                  I doubt. He probably only meant heterosexual males. That's all. He could use different word as well: nerds.

                  Comment


                  • Originally posted by cynical View Post
                    You can also break things very easily. There's array decay, null-terminated strings, lack of type safety (if you do any type casting, which people do), the variable size of int/char, the failure that is the switch statement (although JS has the same problem, for compatibility reasons I suppose :P). The problem with C that the new shiny languages don't have is that a lot of the complexity leads to brittle code.
                    Are you serious? Criticizing the lack of type safety while at the same time approving their use of JavaScript?
                    Yes C has a bad type system, but at least it's better than a language where you can't even declare the types of your variables!

                    Even if safety is a great feature for a language to have, it is not a requirement.
                    If the developer writing the code is somewhat experienced he will instantly see where these issues arise and fix them before even submitting his changes.
                    How many times has a quality program such as the Linux kernel, GNU tools or even Windows crashed for you due to a bad NULL pointer?
                    For me personally that is 0 and I bet very few can count that on one of their hands.

                    On the other hand I have visited multiple sites that fail to load and pressed F12 to see JavaScript type errors, but I'm rather certain that it's because of worse programmers and less testing rather than a fault of JavaScript itself.

                    Comment


                    • Originally posted by cynical View Post
                      You can also break things very easily. There's array decay, null-terminated strings, lack of type safety (if you do any type casting, which people do), the variable size of int/char, the failure that is the switch statement (although JS has the same problem, for compatibility reasons I suppose :P). The problem with C that the new shiny languages don't have is that a lot of the complexity leads to brittle code. You get the best performance, but you need to be a lot more defensive and careful in exchange. The reason Gnome 3 takes more memory is not JS-related anyway. All DEs take more memory than they used to, and that's not automatically a bad thing.
                      Nah, that's not the language's problem. That's a classic problem between the chair and the keyboard right there. How can you blame it on the language is beyond me.

                      The point is that nothing that other languages add is better for the end product (provided you code correctly, again it's a PEBCAK). All they are about is convenience which makes people lazy instead of learning how to code properly. You can't do manual memory allocation in most languages, even if you want to. That means they are inferior because they lack features, man.

                      Hand-holding doesn't make a language good and neither does tolerance for (programming) errors.

                      Originally posted by cynical View Post
                      Have you ever loaded KDE and Gnome in a VM to compare them? At first I was impressed by KDE's lower memory usage, but then I loaded up some apps and especially a browser, and noticed almost no difference between them. Desktop environments are no longer the biggest memory hogs now that you have multi-process browsers running complicated web apps and many applications themselves using browser engines as their base for portability reasons.

                      Ever run Slack? It uses as much memory as Gnome Shell or Nautilus, but it will run on any platform with ease.
                      Sorry but I'm of the thought that something should not take unnecessary resources just because others are hogs. Even if, percentage wise, it's insignificant in comparison. That's still free memory that it eats up which would otherwise be used for what the user wants. Senseless used memory is basically "memory taken away from the user" for what he wants to use. (and not just about memory, CPU resources too) i.e. my (unix old-school) opinion is that it takes away freedom from the user of what he can do with HIS memory.

                      After all, he's the one who bought that memory and CPU, so it's his own freedom. New languages are like "programmer convenience at the expense of end product quality", but it's not the developers (or the language authors) who choose, buy and use the hardware that the end user utilizing the product ends up with. And still, it doesn't change the fact that the end product is way worse with shiny languages compared to C.

                      Originally posted by cynical View Post
                      Well I use Gnome as my DE, and I love the extensions people have written. And there are a number of apps written in gjs that are quite nice, like Polari for example. If you required everyone to use C to contribute, you would simply have fewer contributions.
                      But more high quality ones and in the end, they would be improved and eventually end up with a superior experience. This way it will just be stuck at some point and that's it.

                      Comment

                      Working...
                      X