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

[Weasel]

Looks like forum ate my post and forgot to copy it before submitting, bleh.

So I'll keep it brief in case it really went out the window. To the concerns about C's lack of whatever (btw C does *not* require null terminated strings), most of those are PEBCAK. It's not the languages's fault that the coder doesn't know how to properly manage memory or whatever. And yet, why should users suffer a objectively worse end product because they decided to choose "programmer convenience" over end product quality? Especially when the thread is about the end product and not ABC's adventures coding the software.

tl;dr learn to manage memory properly and to code properly in C, and you see, it's not really missing many features other than compile-time convenience (where C++ excels at in comparison). Don't be part of a PEBCAK.

[cybertraveler]

For your convenience: PEBCAK means: Problem Exists Between Chair And Keyboard.

I had to look it up.

[andy22]

Just a data point... I just set up my odroid xu3 (I also have a rpi3 and didn't try it there though, but I should some time) to work again with GPU accel + Wyaland. I used an Ubuntu 18.04 spin with the Gnome-shell based Ubuntu desktop by default. I can't say for raw out of the box Gnome 3, but memory footprint of the system was:

Booted to text console: 80m
Running Enlightenment (current git master) with 1 terminal up: 156m
Running Ubuntu's Gnome shell with 1 terminal up: 701m

Yeah did a similar test on my old 2 GB laptop, while searching for a OS that could run "adequate" on it and had youtube hardware acceleration for my ancient intel 4500MHD. I noticed that any desktop larger than XFCE took like 1-1.5 GB just to display the same 4 firefox tabs. What shocked me the most was that gnome3 needed like 200-400 MB more than Windows 10.

PS: I also noticed that for many linux distros i tested the boot-up memory consumption was quite misleading, if compared to the final consumption after i started firefox and a texteditor simulating a normal workload.

[Weasel]

Yeah sorry, I'm used to some terms used on mailing lists and forgot that they're not that common.

[cynical]

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!

No need to get defensive. I'm just pointing out that C is not a perfect language, exactly like JavaScript. In JS, you don't have type errors because types are on the data rather than the variable. It's called dynamic typing. I'm not just talking about crashes btw, but security problems, which happen all the time with C.

[cynical]

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.

Because the problems arise from features of the language.

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.

If you think avoiding errors is so important, it's surprising to me that you would be in favor of having an additional vector for mistakes rather than taking the decision out of error-prone human hands. Not having to do manual memory management is a feature. We only tolerate it for the lower level languages because we have to.

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.

If we had to do everything in C, we wouldn't be using this board right now because web technology would be in the stone age. Clearly, there is such a thing as tradeoffs, and a reason why languages like JavaScript exist.

btw C does *not* require null terminated strings

Please educate me. As far as I know, C has to have null terminated strings because of what a string is in C (an array of chars) and the fact that it decays to a pointer. How can you know where the array ends without some kind of symbol telling you, since C doesn't handle those checks itself?

And yet, why should users suffer a objectively worse end product because they decided to choose "programmer convenience" over end product quality?

In many cases, the result is not having a product at all.

[Weasel]

If you think avoiding errors is so important, it's surprising to me that you would be in favor of having an additional vector for mistakes rather than taking the decision out of error-prone human hands. Not having to do manual memory management is a feature. We only tolerate it for the lower level languages because we have to.

Who's "we" again? I get it, 90% of "programmers" out there just treat it as a normal job, they don't think about code outside of their working hours. They just go to get paid, do the job as simple as possible, and be done with it. C to them is a "necessary evil" only in cases where the boss tells them to do it.

C is for real programmers. They code because they care about the end result. Analogous to artistic integrity if you will. And these aren't only my words, obviously the guy who initially wrote the kernel shares these beliefs. You know, people who like to write code and be proud of the result, not just to get it done asap "as long as it works".

Yes, it might have flaws, but those flaws *can* get fixed. They *will* get fixed, so it will be progressively *better* with time.

On the other hand, there is no fix for the bloated runtimes or slowness caused by "modern languages". NO FIX EVER. Forever sucking.

If we had to do everything in C, we wouldn't be using this board right now because web technology would be in the stone age. Clearly, there is such a thing as tradeoffs, and a reason why languages like JavaScript exist.

No, we'd be using a much superior board that loads instantly like it should considering the power of the hardware these days. Obviously, it wouldn't be as quick to develop as this board from scratch, but we'd have one eventually, because people would contribute to fewer projects which end up ultimately better. Hardware doesn't improve just so software can get to shit on its efforts because software devs want to pump out "software" of crap quality.

Of course, using C as a language in a browser is suicide, because you're not supposed to run such a powerful language in a browser. Javascript "makes sense" there, although it should be something even MORE lightweight and simple, since JS is already causing so many security issues in browsers.

See this: http://idlewords.com/talks/website_obesity.htm

Explains it well enough. It is amusing to see how much shit people tolerate these days when we should expect MUCH MUCH better from our hardware. If devs were forced to (i.e. C was the only available language or so), we'd have a much better world.

Please educate me. As far as I know, C has to have null terminated strings because of what a string is in C (an array of chars) and the fact that it decays to a pointer. How can you know where the array ends without some kind of symbol telling you, since C doesn't handle those checks itself?

You can always use your own macros (yes, macro abuse is legit in C, since it doesn't have constexpr metaprogramming like C++). Nobody forces you to use null terminated strings. Make a struct, use byte-prefixed strings or whatever, unlike other languages where flexibility is thrown out the window for "programmer convenience". Ergo, C as a language is superior since you can do both X and Y.

In many cases, the result is not having a product at all.

Yes. Fewer, higher quality products, would be better.

If implementing X project from scratch would be 10x more difficult, people would band together and contribute more to existing projects, ensuring more quality. There will be security vulnerabilities but they will get eventually fixed. Constantly improving instead of "writing from scratch" means you don't throw out all the progress done.
_______

Don't you find it absolutely ridiculous that we get "modern" APIs like Vulkan which are akin to C in the graphics programming world, which crash at the slightest programming error (segfault or even worse, lockup the entire GPU), when we have "bloated" hand-holding APIs before such as OpenGL, which would be akin to idk maybe Python or whatever? We call this "progress" in the graphics world because we need to start squeezing out performance.

But yet, on the other hand, CPUs have been pretty much stagnant for the past decade, with only minor performance improvements. And it's CPUs where we want even WORSE performance from software for "convenience"? To me this is completely absurd, full stop.

[cynical]

Who's "we" again? I get it, 90% of "programmers" out there just treat it as a normal job, they don't think about code outside of their working hours.

Do you enjoy complexity for the sake of it? Time spent on memory management is time taken away from solving problems, and it introduces the potential for mistakes on the part of the programmer. All things being equal, it is objectively not desirable for a programmer to have to do it.

C is for real programmers.

/eyeroll

Javascript "makes sense" there, although it should be something even MORE lightweight and simple, since JS is already causing so many security issues in browsers.

See this: http://idlewords.com/talks/website_obesity.htm

Explains it well enough. It is amusing to see how much shit people tolerate these days when we should expect MUCH MUCH better from our hardware. If devs were forced to (i.e. C was the only available language or so), we'd have a much better world.

Nothing to do with the language. Everyone has a choice on whether they want to load their page with a million scripts/external resources or not.

You can always use your own macros (yes, macro abuse is legit in C, since it doesn't have constexpr metaprogramming like C++). Nobody forces you to use null terminated strings. Make a struct, use byte-prefixed strings or whatever, unlike other languages where flexibility is thrown out the window for "programmer convenience". Ergo, C as a language is superior since you can do both X and Y.

How does a macro, struct, or byte-prefix replace a null terminating character for strings?

[Weasel]

Do you enjoy complexity for the sake of it? Time spent on memory management is time taken away from solving problems, and it introduces the potential for mistakes on the part of the programmer. All things being equal, it is objectively not desirable for a programmer to have to do it.

But it is objectively desirable for him if he cares about the end product.

Nothing to do with the language. Everyone has a choice on whether they want to load their page with a million scripts/external resources or not.

I know, I was simply saying that people are tolerant of too much shit today out of laziness of the developers or whatever other reason. We should demand and expect better.

How does a macro, struct, or byte-prefix replace a null terminating character for strings?

I think I understand your confusion now. Strings are just an array in memory of chars. "blah" is just convenience for { 'b','l','a','h',0 }. You insist on using "blah" (constant literal string) but you don't have to because you're not limited by it. So make a macro without it (well, some compilers have extensions for wide-strings though, like the L macro). You will have to handle it like an array or whatever it is, manually, with macro giving you the field (such as length).

With C++ it's much easier to make a generic class that can even convert -- at COMPILE time (meaning the output is identical and not bloated) -- a string such as "blah" to anything you want. Literally. C is lacking in compile time capabilities, however, but it can be done (just a bit more manually, without using constant string literals). (i.e. use constexpr class, constexpr constructor, or even the literal operator"" in C++)

[cynical]

But it is objectively desirable for him if he cares about the end product.

I'm saying that if you could have the performance of C and a quality end product without having to deal with memory management, it would be preferable not to do memory management.

So make a macro without it (well, some compilers have extensions for wide-strings though, like the L macro). You will have to handle it like an array or whatever it is, manually, with macro giving you the field (such as length).

That's great, you have a workaround. Now imagine if that flaw was not there in the first place and you didn't have to think about any of this whatsoever. That you could just use the normal features of the language without having to code defensively. That's what I'm talking about when I say that C is flawed. You haven't actually solved the problem, because the problem is in the language.

Yes, it might have flaws, but those flaws *can* get fixed. They *will* get fixed, so it will be progressively *better* with time.

On the other hand, there is no fix for the bloated runtimes or slowness caused by "modern languages". NO FIX EVER. Forever sucking.

Now you're just trolling. First of all, many of the problems in C cannot be fixed because it would break backwards compatibility. Second, it was not even feasible to use JavaScript for anything other than simple web scripts in the past, which is why you know it as a 'scripting language', yet today it is used to write entire apps, and is completely displacing languages like Java on the server (where you can always throw more computers at the problem, while you can't say the same thing about developers). That is only possible because of massive improvements to the language and runtimes. So you're objectively wrong here, and you know it.

I actually like C, but I also really like the dynamic nature of LISPy languages. Not everything needs to be directly in touch with the hardware. I assume you like it because it gives you maximum control and efficiency, and believe that mastery over these things is a sign of skill right? I value flexibility and speed of development more. It's not an either/or thing, just a matter of taste. It all matters in the end.