Not vSphere or anything like that, but I had OM Rock 5.0 running in a VMware Workstation Pro VM on a Windows 11 host without any issue.
Hello I’m a new Rome user.
Also caught the Lunduke videos.
Been using various distros as my daily driver over the last 5 years or so.
Currently playing on the side with an ubuntu server and docker on an old laptop.
I’m no expert so I donated a little to help keep the lights on instead.
4 Likes
Thank you very much!
1 Like
There is a way to enable the repo for VSCode in Software Repository Selector. VSCodium would have to be packaged by someone who likes/is comfortable packaging with Electron.
Flatpaks are great and all, appimages too. I just have a preference for native package management.
I still consider the former two as fallback options.
2 Likes
I install my browsers via flatpak lately →
When I distrohop, my apps remain persistent in my user space with my settings. Makes it so much less painful to switch.
it would be something to add as a package request issue on github then 
1 Like
Correct.
Do we need a native package if the flatpak works? Just saying it’s more work for maintainers. Less burden on them, the better 
Yes, that’s the point and benefit of rolling releases, and I think while OM support flatpak out of the box for those that need it (a late addition if I’m not mistaken), they aren’t particular fans of it, they certainly don’t actively endorse it
2 Likes
Exactly. Hell, If I can figure it out I’ll do it myself if need be.
1 Like
Not necessarily, but in many cases, it’s preferable. The main drawback of flatpak and similar things is that they bundle a lot of libraries that already exist in the system - sometimes a different version. So when you’re using flatpaks etc. and we push e.g. a security fix for libjpeg and you update, your flatpak application may still be vulnerable, because we don’t control the version of libjpeg inside the flatpak.
The secondary drawback is just space wasted on all the duplicated libraries.
But flatpak is certainly useful for running non-free stuff in a more or less portable way, and it is certainly a good way to install extra stuff that we simply don’t have time to add to the repos.
But in most cases, a native package is preferable - so if you need/want something that isn’t in the repositories, the best thing to do is to build a package we can add.
3 Likes
I do understand the load on the developers and maintainers. For somethings, like LibreOffice, I would rather see OM drop the repo package and use let everyone use the flatpak version. For some smaller things, like apps that run in the terminal, the flatpaks just don’t seem to work well.
Yes, we could use more Devs and Maintainers.
Personally, no, I am not using all those great fast technologies of lean OM ROME (clang, zen1), no apparmor or selinux that complicate the desktop system for dubious “extra protection”, only to be slowed down by bloaty, insecure containers, otherwise I would just use Debian with flatpaks and be done with it, those are my 2 4 cents 
As you say, the only thing that is needed in a rolling release is more maintainers, then it’s the perfect model.
I didn’t know flatpaks work that way. It makes sense for devs to prefer native packages. Thanks for explaining, bero.
1 Like
There’s also a matter of migrations that preserve the user’s home folder from other distributions, OM doesn’t start users at UID 1000 & with that comes some quirks with tossing on flatpak alternatives, since permissions can get out of wack even after taking ownership again.
one of those being that WINE prefixes break.
edit: even VSCodium’s flatpak builds give you a readme that mentions any quirks you have to work around, due to sandboxing.
1 Like
Maybe hold onto the repo because the flatpak version jumbled up a PDF I tried to edit when I was on KDE Neon 
The good news is the third party repo provided by vscodium does work. repo_gpgcheck doesn’t work though.
I’m just following what Fedora did.
What did they do exactly?