You’re arguing semantics and that’s not the point I’m trying to argue here. Forget the term “Plasma”. I don’t really care about what the DE is branded as or what’s in “Plasma” the software package. When I say “KDE”, I mean the desktop + all the basic default/recommended apps that you’d see on a typical KDE installation, such as Dolphin, Konsole, Kate, Kalculator, Spectacle etc that’s part of the KDE project. IDK whether the apps I’ve mentioned are considered part of “Plasma” or not, but again, that’s not the point, I’m saying this is what I meant when I said “KDE” - and what most people would expect when they picture a “KDE” environment.
Anyways, I tested this myself on two identical VMs with 2GB RAM, one installed with Fedora 40 KDE, and another with Fedora 40 LXQt, both set to use X11 (because LXQt isn’t Wayland ready yet), both updated and running the latest kernel 6.8.10-300.fc40. I logged into the DEs, opened only two terminal windows and nothing else, ran, and ran htop
. The screenshot speaks for itself:
And when I tried disabling swap on both machines, the KDE machine was practically unusable, with only 53MB RAM remaining before it completely froze on me. Meanwhile, the LXQt one was still very much usable even without swap enabled.
I’d like to see you try running without swap and see how it fares. And if you think it’s unfair disabling swap on a 2GB machine - try installing LXQt yourself, disable swap and see for yourself how much more usable it is compared to KDE.
And this is why I say KDE is bloated and not suitable for old machines.
Edit: Also, check out the memory consumption listed by a user in this post: https://lemmy.nz/comment/9070317
Edit2: Here’s a screenshot of the top 30 processes on my test systems, side-by-side:
Of the above, I calculated the usage of the top 10 processes specific to each respective DE, and you can see that KDE’s memory usage is almost double that of LXQt. Had I counted all the DE-specific processes, it’d no doubt be a lot more than double.
Correct me if I’m wrong, but this #OptGreen project isn’t talking specifically about Plasma, is it? They don’t mention Plasma anywhere on the page they linked.
In any case, that’s irrelevant, also, I don’t doubt that KDE can’t run at all under the specs you mentioned - that’s not the issue. The question is, how much free/usable RAM do you actually have on that machine - let’s say with no apps open first, and with then check again with Konsole + Dolphin + KWrite/Kate open? And for fun, fire up Konqueror as well and check again.
Edit: Screenshots proving that what you’re saying is not correct:
I’m not talking specifically about Plasma, I’m talking about the “DE” part of KDE in general; and particularly in this context of repurposing and extending the life of old PCs.
I find it a bit ironic for KDE to be pushing this message, when it’s a heavy DE (relatively speaking) - it’s NOT what anyone would have in mind when when selecting a DE for an old PC.
For instance, take LXQt - run the default/recommended file browser, terminal and text editor, and compare it with KDE + equivalents - you’d see a significant difference in resource consumption. On a system with low RAM, that extra bit of free memory makes a big difference, as it could mean avoiding the penalty hit of the swap file, which you’d invariably run into as soon as you fire up a modern Web browser. So it’s vital that the DE use as little resources as possible on such a machine.
So, are there any plans to reduce the bloat in KDE, maybe even make a lightweight version (like LXQt) that’s suitable for older PCs with limited resources?
Sounds like an issue with your WiFi adapter/driver. You can verify this by creating a mobile hotspot on your phone and connecting your PC to it and see if you get the same issue, if you do then it proves it’s got nothing to do with your router.
Another thing you can check is your journalctl logs - run journalctl -f
before launching the game, then run the game and quit it when you run into the DNS issue, and check the logs at the time the issue occurred. If there’s indeed a hardware/driver issue, the errors should show up in the logs.
If it’s a driver issue, there may not be much you can do about it besides reporting the bug and implementing some sort of workaround (eg using a VPN). Of course, depending on the error, there may be a fix you can apply, like turning of aspm for your chip. A better option would be to replace the WiFi chip/adapter you’re using and get something that’s better supported under Linux, like something with an Intel or Atheros chip. But check journalctl first and see how it goes from there.
In the footnotes they mention GPT-3.5. Their argument for not testing 4 was because it was paid, and so most users would be using 3.5 - which is already factually incorrect now because the new GPT-4o (which they don’t even mention) is now free. Finally, they didn’t mention GPT-4 Turbo either, which is even better at coding compared to 4.
You’ll need to bind a hotkey to a third-party tool such as ydotool.
Eg using ydotool, the command would be ydotool click 0xC1
You cannot go back after trying it
I did! Used to have a Samsung 49" ultrawide. After using it for a couple of years, I sold it and got a 16:10 32" QHD, which I found worked better for me (+ one or two laptop screens for chat / random stuff when I’m doing serious work).
The biggest issue I had with the ultrawide is that most of the games that I played weren’t optimised for it, especially in some games where things like the mini-map might be at the far end of the screen, or worse, if it was an older game then you’d have to put up with black bars, or play the game in windowed mode.
I don’t play D4 anymore so I can’t say if this still works, but back when I did, I used to launch it (ie the Battle.net launcher) from Steam, as a non-Steam game.
I also used the latest Proton-GE as the compatibility tool, so that’s something you could try as well.
IMO you shouldn’t look at it as “should I become an x user”, because that sort of implies you’re getting married to that distro. Instead, you should be asking, “should I use x to solve y?” For instance, I use RHEL, Debian (Raspbian), Fedora (Asahi), Fedora Atomic (Bazzite) and Arch. I also use Windows, macOS and FreeDOS. All solve different needs and problems. There’s no rule saying you should only stick to one distro/OS use whatever suits your needs, hardware and environment the best. :)
Because MIUI deviates from stock Android so much that it often causes unexpected behaviour and bugs. So it’s easier for developers to just say they don’t support it, instead of putting up with negative reviews and complaints.
This is a general tech community, mostly centered around news and end-user technology discussions, so it’s very unlikely you’ll get an answer here. Might want to try asking on Reddit or some dedicated Datto/Connectwise forum.
Well I haven’t used Plasma Mobile or any of the apps you’ve mentioned, so it’d be nice to see what it all looks like! (and I don’t have a device I can try it on either, unless I can get it working with Termux + Termux-X11?)
Nice writeup, but it would’ve been nice if you added some screenshots or a short video of your setup!
Kiwi here, no such issues with my Sync. Is there a particular community where you see these errors mainly (if so, can you link it here)?
Also, when you get those errors, it might be worth accessing that community directly using a local account - and if the images load fine, that would point to a federation issue with your server.
Considering that predicting the next word from context is the one thing LLMs are really good at, I just don’t understand how none of these developments have found their way into predictive keyboards.
The problem is that LLMs require a considerable amount of computing power to run, unlike the simple markov chain predictions that keyboards use. You could use a cloud-based service like ChatGPT or something, but most people wouldn’t want their keyboards to send all their keystrokes to a remote server… and even if they didn’t know or care, the response time wouldn’t be good enough for real-time predictions.
Now smartphone SoC makers like Qualcomm have started adding NPUs (neural processing units) with their latest chips (such as the SD8 Gen 3, featured in the most recent flagship phones), but it’s going to take a while before devices with NPUs become commonplace, and it’ll take a while for developers to start making/updating apps that can make use of it.
But yeah the good news is that it is coming, it’s only a matter of “when” - I suspect it won’t be long before the likes of SwiftKey start to take advantage of this.
The answers here are only partially correct. If you want to use your device internationally, there are four things or categories you need to consider:
Carrier locked devices are exactly that, these are the ones sold by your carrier and subsidised, they usually mention that you can’t use them with other carriers. Eg the SM-S928U of the S24 works only on AT&T. If you have one of these, you may be able to buy an unlock code online to unlock your phone. Depending on your model, you might also need to flash compatible firmware or unlock additional bands from the service menu, if you want to be able to actually use it with your destination carrier.
Region-specific devices generally have limited cellular bands, meant for usage in that country. Eg although the SM-S928U1 variant of the S24 is factory unlocked (unlike the SM-S928U), it may not carry all the bands required for operation outside the US. If you’re unsure about compatibility, use this website to check the bands for your target country/carrier. Generally though, if you travel a lot, it’s recommend to buy the international / global variant of a phone. As an alternative, if you have a US variant Samsung, you could use the service menu to enable all bands. Though regardless of the variant, it’s always a good idea to check the band compatibility before you purchase the device/travel.
Carrier whitelisting is a recent annoying thing which carriers have started doing for some technologies such as 5G, VoLTE, VoWiFi etc. Some of these features may or may not be critical for you, for eg, if the destination carrier no longer offer 2G/3G services, that means you must be able to get VoLTE in order to make calls. And VoWiFi is needed if you’re in an area with poor reception, but have WiFi access. Finally, 5G would be a bonus thing but most carriers allow only whitelisted models to connect to their 5G services. Samsung normally should work in general, but given how many variants Samsung makes, there’s no guarantee that your specific variant would be able to use some/all of these services. So you’ll need to check with your target carrier in advance to see which of their services your phone would be able to support.
Finally, some countries may have regulatory requirements which may legally prevent shops/carriers from selling you a SIM card, if your phone isn’t in their database. For instance, in Japan, it’s technically illegal to operate a device without a “giteki” mark - and if your phone doesn’t have this, operators may refuse to sell you a card. In this case however, you should be fine if you order a compatible SIM/eSIM online before arrival (eg from Sakura Mobile).
It’s easiest to just register a domain name and use Couldflare Tunnels. No need to worry about dynamic DNS, port forwarding etc. Plus, you have the security advantages of DDoS protection and firewall (WAF). Finally, you get portability - you can change your ISP, router or even move your entire lab into the cloud if you wanted to, and you won’t need to change a single thing.
I have a lab set up on my mini PC that I often take to work with me, and it works the same regardless of whether it’s going thru my work’s restricted proxy or the NAT at home. Zero config required on the network side.
I’m not moving any goalposts. You’re the one arguing about the semantics around “Plasma”, and I keep saying that’s irrelevant.
Refer back to my original comment which was, and I quote:
To clarify, here I was:
The ENTIRE point of my argument was the KDE isn’t really ideal RELATIVELY, for older PCs with limited resources, and I’m using LXQt here are a reference.
In a subsequent test, here’s a direct apples-to-apples(ish) component comparison:
plasmashell
was sitting at 250MB btw in this instance btw.The numbers speak for themselves - no one in their right minds would consider KDE (or
plasmashell
, since you want to be pedantic) to be “light”, in RELATION to an older PC with limited resources - which btw, was the premise of my entire argument. Of course KDE orplasmashell
might be considered “light” on a modern system, but not an old PC with 2GB RAM. Whether something is considered light or bloated is always relative, and in this instance, it’s obvious to anyone that KDE/plasmashell
isn’t “light”.