Honestly, it’s very reasonable and even responsible to wait a bit (a week or two perhaps) before using a new version, especially given that 0.19.5 came swiftly after 0.19.4 due to some bugs. And of course anyone running a fediverse instance is a volunteer so it’s probably not reasonable to put deadlines or pressure on themselves. But I won’t speak for the admins on programming.dev and of course asking is perfectly fine, just don’t expect an answer :)
Interesting, thanks for sharing
You didn’t read my whole post it seems.
You are getting the whole story - not sure what it is you think is missing. But I mean a serious desktop contender has to take UX seriously and have things “just work” without any custom configuration or tweaking or hacking around. Currently when I compile on Windows my browser and other programs “just works” while on Linux, the other stuff is choppy and laggy.
I actually tried that but I had to reduce it all the way to 4 jobs, which slows compilation down a lot.
I am on Wayland actually
Yes Firefox, yes NVMe. No, there is no IO happening and again, sitting at relatively low memory usage. I was not running anything else than the compiler, my editor and Firefox. I’m fairly confident the CPU usage is the culprit as memory usage is not severely affected and disk usage by the compiler should be pretty minimal (and I don’t see how disk usage would make Firefox slow if there’s still plenty of RAM available).
Neither KDE nor Gnome is peak Desktop Linux experience. Ubuntu and its flavors is not peak distro experience either.
If you want to try Desktop Linux for real, you will need to dip your toes a little bit deeper.
I’ve heard much of the opposite - KDE is touted as an easy-to-use desktop and Ubuntu is largely a popular “just works” distro. And honestly that has been my primary experience. Mostly everything works, but there are some hiccups here and there like the problem I posted about in this thread.
What alternative would you suggest?
If that’s the solution to the problem, it’s a good solution. Linux ought to do the same thing, cause none of the suggestions in this thread have worked for me.
That might be the case, but that makes me sad though. That implies that Linux is only targeting technical people who are willing to tinker with all these things themselves.
I would personally want Linux to be broader than that. I’d want it to be the option for everyone - free computing shouldn’t be limited to technical people, it should be provided to all.
Thanks for all the work!
So I just tried using nice -n +19 and it still lags my browser and my UI. So that’s not even a good workaround.
I wonder if Linux should also provide server and desktop variants like Windows does, with different scheduler settings and such. The use cases are quite different after all, it’s kinda weird they use the same settings.
I have a worrying feeling that if I opened a bug for the KDE desktop about this, they’d just say it’s a problem of the scheduler and that’s the kernel so it’s out of their hands. But maybe I should try?
That’s all fine, but as I said, Windows seems to handle this situation without a hitch. Why can Windows do it when Linux can’t?
Also, it sounds like you suggest there is a tradeoff between bandwidth and responsiveness. That sounds reasonable. But shouldn’t Linux then allow me to easily decide where I want that tradeoff to lie? Currently I only have workarounds. Why isn’t there some setting somewhere to say “Yes, please prioritise responsiveness even if it reduces bandwidth a little bit”. And that probably ought to be the default setting. I don’t think a responsive UI should be questioned - that should just be a given.
Rust is simpler than Go or Python when a system scales.
A program with 1000 lines will be simplest in Python because it’s just 1000 lines right? Doesn’t matter.
A program with 1000000 lines will be much easier and simpler to work with in Rust than in Python or Go. The static analysis and the guarantees that the compiler provides suddenly apply to a much larger piece of code, making it more valuable.
Python offloads type checking to the programmer, meaning that’s cognitive space you gotta use instead of the compiler. Go does the same with error handling and for inexplicable reasons use the billion dollar mistake even though it’s a relatively modern language.
It is in this way that Rust is simpler than Go and Python. Also, because a system is likely to grow to a larger size over time in a corporate setting, Rust should be preferred in your professional workplace rather than Python or Go. That’s my take on it.
Honestly, Go is a weird language. It’s so… “basic”. It doesn’t really provide anything new that other languages haven’t done already, perhaps aside from fast static compilation. If it wasn’t because Google was pushing it, I don’t believe Go would ever have become as popular as it is.
Sure but that’s not what the person I replied to suggested.
Sure, it could lock up the UI if there is no input for a while I suppose. But if there is still input, then it should be responsive.
I believe it can achieve both.
As I mention at the end, this situation has nothing to do with running out of memory. It’s purely CPU starvation.
I only said as fast as possible - I generally think the compile times are fine and not a huge problem. Certainly worth it for all the benefits.
Nice sheet, though I have a few critiques:
where T: Sizedfor references&T? A reference can definitely point to an unsized type, e.g.&str.&T,&[T]and&dyn Trait) may either point to the stack or the heap.