My Nextcloud has always been sluggish — navigating and interacting isn’t snappy/responsive, changing between apps is very slow, loading tasks is horrible, etc. I’m curious what the experience is like for other people. I’d also be curious to know how you have your Nextcloud set up (install method, server hardware, any other relevent special configs, etc.). Mine is essentially just a default install of Nextcloud Snap.
Edit (2024-03-03T09:00Z): I should clarify that I am specifically talking about the web interface and not general file sync capabilites. Specifically, I notice the sluggishness the most when interacting with the calendar, and tasks.
Have you read my comment? It’s about where the packages and services are installed.
In this case, they’re installed in the container, not on the host
What is it you think the “metal” is in in the phrase “running on bare metal?”
Your comment is irrelevant. Who cares in what directory or disk image the packages are installed? If I run in a “chroot jail” am I not “running on bare metal?” What if I include a library in /opt/application/lib? Does it matter if the binaries are on an NFS share? This is all irrelevant.
The phrase means to be not running in any emulation. To answer my question above - the “metal” is the CPU (edit: and other hardware).
edit2: I mean - it’s the defining characteristic of containers that they execute on bare metal unlike VMs and (arguably - I won’t get into it) hypervisors. There is no hardware abstraction at all. They just run natively.
It’s just what it means in this specific context.
They’re not running directly on the host, with directly meaning directly.
If you go by definition, I agree with you, but the definition is not always the thing to go off of.
Yes. They are BTW.
Is docker virtualized or otherwise emulating something? It’s just a way to package things, like an installer? Then it’s bare metal.
I had to look this up too, I thought docker containers were virtualized.
“I used the wrong words but I feel like justifying them as right.”
This is that whole “I know literally means literally the opposite of what I meant but deal with it” bullshit. Whatever, I’ll not argue with such lunacy. Words mean whatever you want them to.
Words evolve, and sometimes, they gain new meanings. “Bare metal” is not a scientific terms, and so it can be bent depending on the context.
You can either accept that or not, it doesn’t change the fact that that’s what it now can mean.
Let me put it this way - you can accept the fact that the words you chose are not only wrong but also misleading since not everybody will understand your specific meaning in this context, or you can use the right friggin’ words.
Saying “containers aren’t running on bare-metal” makes a claim about the performance of applications running in a container vs. the host OS. In reality there will be zero or negligible difference.
Your job as a speaker is to be understood - if you’re not going to do that then people will be confused and it’s your fault for the confusion.
That is not an excuse to misuse terms.
In this case the phrase is blatantly being misused or misunderstood by the person using it.
He look - I drive a car with a V8! I mean I know it only has 4 cylinders in-line but I count them twice and I like the letter “V” so in this specific context it’s a V8!
No. Your packages and services could be on a network share on the other side of the world, but where they are run is what matters here. Processes are always loaded into, and run from main memory.
“Running on bare metal” refers to whether the CPU the process is being run on is emulated/virtualized (ex. via Intel VT-x) or not.
A VM uses virtualization to run an OS, and the processes are running within that OS, thus neither is running on bare metal. But the purpose of containers is to run them wherever your host OS is running. So if your host is on bare metal, then the container is too. You are not emulating or virtualizing any hardware.
Here’s an article explaining the difference in more detail if needed.