- cross-posted to:
- softwarequality@infosec.pub
- cross-posted to:
- softwarequality@infosec.pub
You must log in or # to comment.
It’s not running out. It’s being hoarded for the entropy machine.
Edit: anyone know if entropy machine ram can be salvaged for human use? If they use the same sticks?
Server memory is probably reusable, though likely to be either soldered and/or ECC modules. But a soldering iron and someone sufficiently smart can probably do it (if it isn’t directly usable).
So it’s salvageable if they don’t burn it out running everything at 500c
500°C would be way above the safe operating temps, but most likely yes.
You think the slop cultists care?
Yes, actually. Data centers are designed to cool down components pretty efficiently. They aren’t cooking the RAM at 500°C.
500 might be hyperbole, but they do burn the things pretty hard. Not at like a real data center, but for the slop cultists.
Yeah, gonna be interesting. Software companies working on consumer software often don’t need to care, because:
- They don’t need to buy the RAM that they’re filling up.
- They’re not the only culprit on your PC.
- Consumers don’t understand how RAM works nearly as well as they understand fuel.
- And even when consumers understand that an application is using too much, they may not be able to switch to an alternative either way, see for example the many chat applications written in Electron, none of which are interoperable.
I can see somewhat of a shift happening for software that companies develop for themselves, though. At $DAYJOB, we have an application written in Rust and you can practically see the dollar signs lighting up in the eyes of management when you tell them “just get the cheapest device to run it on” and “it’s hardly going to incur cloud hosting costs”.
Obviously this alone rarely leads to management deciding to rewrite an application/service in a more efficient language, but it certainly makes them more open to devs wanting to use these languages. Well, and who knows what happens, if the prices for Raspberry Pis and cloud hosting and such end up skyrocketing similarly.many chat applications written in Electron, none of which are interoperable.
This is one of my pet peeves, and a noteworthy example because chat applications tend to be left running all day long in order to notify of new messages, reducing a system’s available RAM at all times. Bloated ones end up pushing users into upgrading their hardware sooner than should be needed, which is expensive, wasteful, and harmful to the environment.
Open chat services that support third party clients have an advantage here, since someone can develop a lightweight one, or even a featherweight message notifier (so that no full-featured client has to run all day long).
Open chat is good in theory but corporate overlords need control. We can ignore them, but that is a lot of laptops with a lot of memory
I feel like it’s as much the number of libraries as the language. There are many bloated C/C++ applications.
TUI enthusiasts: “I’ve trained for this day.”
P.S. Yes, I know a TUI program can still be bloated.
deleted by creator
But how can I get anything done with these meager 128 GB computers?
Hah, wishful thinking
Relevant community: !sustainabletech@lemmy.sdf.org
deleted by creator
Rust programs can definitely still consume a lot of memory. Not using a garbage collector certainly helps with memory usage, but it’s not going to change it from gigabytes to kilobytes. That requires completely rethinking how things are done.
That said I’m very much in favour of everyone learning Rust, as it’s a great language - but for other reasons than memory usage :)
deleted by creator
Memory leaks are more than possible in rust. Rust type system prevents things like free being called on an already free resource. It very much also allows not calling free even when nothing references things. It also makes things like arena allocation a fun endeavor compared to other systems languages. It’s not impossible just trickier. Rust isn’t a panacea, you would need something more like idris with its type system to programmatically enforce resources are freed at runtime during the compilation phase. But a fully dependent type system is very much a bleeding edge thing.
.clone() everything!
I do kind of agree in a way though. Rust forces you to think a bit about memory and the language does tend to guide towards good design. But it’s not magic and it’s easy to write inefficient Rust too. Especially if you just clone everything. But I personally find Rust to be a good mix of low level control that feels sufficiently high level.
Garbage collected languages can be memory efficient too though. Having easily shared references is great!
After you’ve cloned everything you’ll
Arc<Mutex<>>everything.
it might be time for me to learn GPUI, i wonder if it’s any good.
I was impressed with GPUI’s description of how they render text, and hope that it either grows into a general purpose GUI toolkit, or inspires one with a similar approach. It has a long way to go, though.
You might find this interesting:
https://github.com/longbridge/gpui-componentIn the meantime, Qt is still the only cross-platform desktop toolkit that does a convincing job of native look and feel. If you’re not married to Rust, you might have a look at these new Qt bindings for Go and Zig:
https://github.com/mappu/miqt
https://github.com/rcalixte/libqt6zig
I’m not sure what there’s less excuse for, the software bloat or the memory running out.
