Wouldn’t it be easier and also make sense … just to keep the rolling release
and only KDE plasma, since it is a huge workload that is resting on all OM-developers,
in the end, you would have less work and still an outstanding OS with more focus and
less work?
Would it be easier? Most definitely. But would it be a good idea?
There probably is not much of an alternative to the current release model. We need Cooker so developers can make changes that break things badly (even changes that break the system totally for normal users for a while – this is expected when we’ll switch from Plasma 5 to Plasma 6, for example).
We need Rolling so users can get current improvements without risking breaking their system by running Cooker.
From a desktop user perspective, we could potentially drop the stable point releases - but that’s dangerous for server users. Imagine you’re running e.g. a webserver that hosts 1000 customer websites using your custom webapp, you update the distro to get some bugfixes, and it breaks your webapp because you get an update to PHP 8.2 which drops some legacy function your webapp relies on. On a server (especially one running some stuff that isn’t part of the distro, and therefore won’t be tested when we update something), you typically want to avoid such nasty surprises - so you want to use Rock/point releases.
Dropping some desktop options would be less work, but keep in mind that this is a pure volunteer project. If this were a company contributors in paid roles, we could tell them “your work on ABC isn’t needed, we want you to work on XYZ instead”. But if you do this in a volunteer project, the more likely answer you’ll get is “But I like ABC and XYZ sucks. **** you. I’m leaving the project and starting my own project that drops XYZ and does ABC!”
The reduction in effort would go along with a reduction in manpower - which in the end is worse than the extra effort.
1 Like
thanks for the detailed answer, this idea was just shooting out from me,
you will better know what fits the workflow of the team in order to
bring along this distribution.
I think @ycom1 has made some very good points.
I’ve never used OM before but installed ROME in a VM and I was very impressed, also compared to Mageia 9 which is less polished imho. From an outside perspective I think that:
- The first impression is great, clean desktop, good welcome app, nice installer, good graphics while booting and in SDDM, and most importantly: Discover and Flatpaks are preinstalled
- I would offer an optional “Minimal install” which comes with only the very basic apps.
- Package management is a bit confusing, I’ve seen four applications, “Discover”, “dnfdragora”, “dnfdrake”, and “update system” (which just runs the update script in Konsole). I think ideally Discover is enough, plus a repository manager in the control center.
- Add some kind of rollback feature for when an update breaks something. openSUSE uses btrfs snapshots but I’m sure there’s other (simpler) approaches as well.
- Drop the alternative desktops to make it easier for the developers. I bet most people who are interested in OM prefer KDE! There’s tons of distros with GNOME already, but few with KDE as a first class citizen, so this is really something where OM can be different. I don’t think a GNOME fan will go for OM instead of e.g. Fedora or openSUSE?
- Drop the stable version to make it easier for the developers. I doubt that there’s many people who use OM on their server. And I don’t think anyone will see OM in the same league as Debian, Ubuntu, RHEL, SUSE, …
- You might as well drop the ARM version then
- You might be able to drop some applications that are available as Flatpaks. I know some people don’t like the idea of having some libraries/dependencies installed twice (RPM and Flatpak) but I mean on the OMA Github you have only 7 people listed so I would prioritize getting the base system polished and up to date and outsource a lot of other stuff to Flatpaks. That’s the general direction anyway, e.g. Fedora Kinoite, openSUSE MicroOS, …
- See if there’s any way of working together or merging with the Mageia community. I’m not sure what’s the reason for the split - do these two groups hate each other or something? - but it just seems a bit silly to have these two distros with the same origin and same goals. Mageia seems to have the bigger community but they are struggling to release version 9 so that indicates to me that both are spread thin.
Welcome to OpenMandriva and our forum.
We are a small group. All the contributors and developers here are unpaid volunteers.
You are welcome to talk to our developers at OpenMandriva Chat.
OpenMandriva wiki and Forum Resources guide.
For serious technical issues and package/feature requests please file a bug report here.
Hope you and other users find this helpful. This is a mix of my personal opinion and my attempt to speak as a member of the OM contributor group. Any errors are mine alone. Be forewarned OpenMandriva Lx is a Community distribution of Linux. We are not bashful about telling users if you want things to be better help us do it. None of us are being paid.
The ROME Plasma slim isos are minimal but graphical installs. You will find them here.
Personally I would agree. My official response is using GUI package managers for OM is a waste of effort. It easy and fast to use dnf commands from Konsole (terminal). People who do this usually have far fewer issues. Among the GUI managers dnfdrake is clearly the best IMO. Doing package management is an easy way for less technical users to learn the command line a bit and get comfortable using it. I would do this in any Linux distro.
dnf downgrade does this. In a lot of instances user will need to manually download the older package/s. Post here and we can help with that.
There may be other ways to do this I am not aware of.
The alternative desktops are Community spins not contributions from OM devs. It remains to be seen how well these can be maintained. If users that use them step up and help the people making these I predict success. A Community distro depends on that Community for it’s success. (OM devs do the Plasma and LXQt releases.) The Plasma slim effort is the work of a contributor @rugyada. The Gnome3 release and I think xfce4 are the work of contributor/developer @AngryPenguin. I appreciate their efforts.
Explained above in this thread by @bero.
IMO in some important way I believe OMLx is better than any of those. But I am obviously prejudiced.
The ARM and soon to come RISCV are considered by OM devs to be architectures of the future. As OM’s mission is to be a very forward looking distributor of open source software this is very much a part of the OMLx project. As @bero says above dropping these means losing developers. If everyone involved is a volunteer then OM has to allow them to do what they want to do at least part of the time.
I am not sure of this but I believe this is the opposite of the goals of OM developers. Things like FlatEarth, excuse me FlatPak, create a hodge podge of conflicting library packages. This can be detrimental to system performance. One of the unique things about OMLx is that if a package is in our repos it was built by OM in our own build system (ABF or Automated Build Farm). Our sources are all under OM control here.
To me personally this is a very important point: OpenMandriva the distro (OMLx) follows the lead and direction of OpenMandriva Association council and the OM Technical Committee. The TC-committee consists of OM devs and other contributors. We have no committment to follow the lead of any other Linux distro, we do collaborate with other distros and projects. There has been some collaboration with Mageia. My observation is that opportunities for such collaboration are limited. One distro being noticeably more forward looking and aggressively upgrading software on OMLx Cooker our development platform. The other group prefers a more conservative approach. FWIW OMLx Rock is our more conservative release point appropriate for business and server use.
Workflow is Cooker>ROME(rolling)>Rock. There are multiple testing step before packages get to ROME. Then the best possible testing takes place by ROME users using this software in real world usage plus another testing step before any package gets to Rock. Similar to Rawhide>Fedora>RHEL or openSUSE Factory>openSUSE Tumbleweed/Leap>SLED/SLES. There are other similar examples.
Another way of looking at this is that for the most part the same packages are available in all versions of OMLx. Cooker having the newest then ROME and Rock having the older versions.
If you use Cooker you need to have the patience and ability to deal with problems. We guarantee that Cooker gets broken at times. Things naturally get broken in the development process, this is normal and expected. This is true of any development platform I have encountered.
1 Like
altlinux also uses packagekit for updates and snapshots for rollbacks if the update was not successful, but unlike opensuse, it comes out of the box, and it still needs to be configured in opensuse.
for this utility, I made an offer on GitHub
why would anyone want to have yandex browser in the repo, makes no sense to me
… and also this proposal does not fit in this “…makes sense…” discussion / thread.
The point here is: hard to say what may be ‘easier’ and/or what may ‘make [more] sense’, just because everyone has own opinion on that. It’s ok, and legit.
Really no way to make a choice which will plase everyone.
The best we can do is to offer some standard options as default for the most common cases at our best understanding, and provide alternatives when at all possible.
Last but not least, by experience whatever you do may be wrong to someone else:
OM focused on KDE desktop?
results in “Hey guys why not provide also Gnome (or put one at your choice) ISO?”
OM providing more alternative desktops?
results in “Hey guys why you waste your time providing alternative desktops and not just focus on KDE only?”
Just one example among gazillion of such, always recurring. Every time. You can’t escape 
the proposal to make OM just for KDE, and also just rolling is very subjective
and I learned about backgrounds to this from @bero’s post,
all in all you do an outstanding work keeping OM running so well, thanks again.
… my questions to this thread are all answered. You can close it if you like.
2 Likes
Sure, as you say you did. However for the benefit of others and for the record won’t hurt to repeat
it’s just an optional connection, like the same Skype.
Thank you, that was a very insightful post.
dnf downgradedoes this. In a lot of instances user will need to manually download the older package/s. Post here and we can help with that.
But that doesn’t really help if the system isn’t bootable or no graphics or the user simply doesn’t know which specific package broke something. I think having something like Snapper or Timeshift out of the box would be very helpful.
My official response is using GUI package managers for OM is a waste of effort. It easy and fast to use dnf commands from Konsole (terminal). People who do this usually have far fewer issues. Among the GUI managers dnfdrake is clearly the best IMO.
But historically Mandriva has been a distribution with the aim of making Linux very easy to use even for newcomers and giving them lots of GUI tools (such as the Control Center). So it doesn’t really make sense to exclude package management from that. In my personal opinion a combination of the om-repo-picker and Discover with packagekit backend would be very user friendly and not as confusing as having multiple tools. Of course you can still use the CLI if you want.
it is better to use discover with packagekit. there is an opportunity to take snapshots before updating. How it was implemented in the viola. So that in case of anything it was possible to roll back the system.