 DistroWatch Weekly |
| Tip Jar |
If you've enjoyed this week's issue of DistroWatch Weekly, please consider sending us a tip.
(Tips this week: 2, value: US$25) |
|
|
|
 bc1qxes3k2wq3uqzr074tkwwjmwfe63z70gwzfu4lx  lnurl1dp68gurn8ghj7ampd3kx2ar0veekzar0wd5xjtnrdakj7tnhv4kxctttdehhwm30d3h82unvwqhhxarpw3jkc7tzw4ex6cfexyfua2nr  86fA3qPTeQtNb2k1vLwEQaAp3XxkvvvXt69gSG5LGunXXikK9koPWZaRQgfFPBPWhMgXjPjccy9LA9xRFchPWQAnPvxh5Le paypal.me/distrowatchweekly • patreon.com/distrowatch |
|
| Extended Lifecycle Support by TuxCare |
|
|
| Reader Comments • Jump to last comment |
1 • Peripheral to uniersal pkg mgrs (by murfi on 2024-10-07 01:08:37 GMT from United States)
I still think there should be some distros which are statically linked. Dynamic linking largely came about due to the lack of ram/disk space. We don't have that problem now.
2 • Static linking (by Jesse on 2024-10-07 01:24:06 GMT from Canada)
@2: "Dynamic linking largely came about due to the lack of ram/disk space. We don't have that problem now."
Dynamic linking also allows one library to be fixed (or updated) and to have that fix applied to all programs which use the library. Imagine, for a moment, glibc patches a fix. Do you really want to re-install almost every package on your system every time that happens? That's what you'd face with static linking, basically re-installing your whole operating system whenever a really low-level package published a security update. I don't think you want to re-install every desktop application every time GTK or Qt patches a vulnerability either.
Imagine running a rolling release distro! Any time a commonly used library had a major update you'd end up re-installing or re-building every package.
Sure, we don't have as many limits in terms of disk or memory anymore, but a lot of people still have limits on their bandwidth and/or the time they are willing to spend updating their operating system.
3 • UNIVERSAL PACKAGE, manager, etc.... (by Greg Zeng on 2024-10-07 02:12:33 GMT from Australia)
All operating systems have these problems. In order of user popularity: Windows, Apple, Android, Linux, BSD,...
ALL systems have ease of updating, adapting to existing hardware-software-settings, error detection-correction, updates, waste removal, and user notifications.
Most systems have simple or complex ways to compile from raw source code. In Linux, raw source code compiling could be hidden in GZ compression, AUR and similar script code instructions, or as script code of compiled application codes.
Third-party application writers prepare ready-to-run DEB files in the form of the one Debian compilation code. An AUR script code can compile raw source code into easy DEB code.
According to MajorGeeks, the second most used Linux code favoured is any of the many incompatible forms of RPM compiled code; either the one official RPM Red Hat brand name or any of the unofficial RPM codes (SuSe, PCLOS, Mandriva, etc).
The third most popular 'universal package' chosen by independent application writers is the Ubuntu APT instructions. Of the 128 Debian-based Linux brand names, https://distrowatch.com/search.php?ostype=All&category=All&origin=All&basedon=Debian¬basedon=None&desktop=All&architecture=All&package=All&rolling=All&isosize=All&netinstall=All&language=All&defaultinit=All&status=Active#simpleresults
https://distrowatch.com/search.php?ostype=All&category=All&origin=All&basedon=Ubuntu¬basedon=None&desktop=All&architecture=All&package=All&rolling=All&isosize=All&netinstall=All&language=All&defaultinit=All&status=Active#simpleresults
there are 52+18 based on Ubuntu, which then uses this PPA system.
Also ran in the 'universal package system', in order of application writer, are Flatpak, Appimage, Snap, and Puppy. Each of these closed systems is lacking in application choices, and in staying alive to the newest updates of the raw, uncompiled codes.
Most application writers, including those specializing in Linux-only applications, often prefer to also offer the most used operating systems with their Linux-only applications. For example, Kdenlive & Shotcut video editors.
Most applications, including FreeFileSync, Slimjet & Ventoy, are hard to find in any Linux ready-to-run compiled code. Hopefully, either Flatpak or Appimage might become more used in Linux. Otherwise, Linux will stay with its 2 - 4 % popularity, of all computer operating systems.
4 • Unified package manager (by Vinfall on 2024-10-07 02:12:41 GMT from Singapore)
So what does a unified package management do exactly behind the scene? The description sounds like nothing more than a wrapper/alias for various (traditional) package managers.
I used to consider it as a universal converter which would translate different types of package (RPM/DEB/XBPS/whatever) by parsing package info & (probably via multiple params) installing it into a unified place (or better, convert every weird package format into the one used by current distro).
That's how I conclude that it is hacky and should be avoided, as usually such thing is not recommended due to the very likely brokerage & different (sometimes even contradictory) packaging guidelines.
Do things change recently and this can already done properly?
5 • @ 4 • Unified package manager (by Because; reasons on 2024-10-07 03:18:59 GMT from New Zealand)
mostly agree with your take, 'happy to be wrong and have the error of my ways corrected'.
Each of the various package managers, apart from retrieving and installing required packages, keep track of those pesky dependencies, and have an 'internal to themselves' record of installed packages.
When you have more than one, the 'internal record of installed applications' ( and dependencies) will differ, so, even by using a wrapper to invoke the required package-manager per package type is fraught with risk, to my simple mind.
If RhinoLinux have truly managed to overcome this, kudos to them.
I am aware that one .rpm distro offers 2 package managers, and recommend using one, and sticking with it for the life of the installation.
6 • Redox opinion (by Timothy L. Miller on 2024-10-07 04:16:51 GMT from United States)
IMO, still FAR too early to bother. Downloaded the demo and desktop images to try in QEMU/KVM with virt-manager as a frontend. Neither even booted to test. Worthless garbage at this point unless you're a developer wanting to work on the project.
7 • Static linking... (by Vip2 on 2024-10-07 04:22:44 GMT from United States)
@2
"Sure, we don't have as many limits in terms of disk or memory anymore, but a lot of people still have limits on their bandwidth and/or the time they are willing to spend updating their operating system."
Bandwidth is also not really an issue if Delta updates are used to update the static packages. No need to download the whole package, only the changes. Whether or not that is fully implemented is something I am not sure of. I did find some posts about flatpacks supporting delta updates in Fedora from 2020
8 • Redox (by Andy Prough on 2024-10-07 05:15:31 GMT from Switzerland)
I tried Redox, and it seems pleasant but you can't really do anything useful with it, it's just a demo.
I don't really see the point of reviewing a demo that has no ability to do any productive work or run any useful programs. Seems better to wait to see if it ever becomes anything or if it just dies out like so many of these projects.
9 • Unified package managers/universal package formats (by grraf on 2024-10-07 07:11:59 GMT from Romania)
It all sounds so nice in theory but in practice all we get is a lot of extra bloating(since everything and its mother comes with its required dependencies to run regardless of distro in the case of universal packages) and a lot of potential mishaps and conflicts can occur when a UPM starts calling&giving each successive package manager free reign to alter the OS... its no coincidence most sane distros advise sticking to&using just one package manager.
As far as i'm concerned both practices are to be avoided , not encouraged but its no skin of my back if folks care to play russian roulette with the integrity of theyr OS... ill be blunt and say it: if you need an up to date distro then switch to a rolling one and if you want access to a larger repo of apps then switch to a distro that has just that...
Stop trying to turn your honda civic into a ferrari by slapping in random parts into it that weren't designed to fit in there in the first place just so you could avoid moving away from the ever so familiar&comfortable honda civics controls&design... you are just stalling the inevitable while asking for trouble in return for your misguided 'efforts'
10 • RedoxOS (by uz64 on 2024-10-07 07:48:24 GMT from United States)
I tried Redox OS and it is too early to give a real opinion on it because it has so far not come even close to the standards I would expect for a "usable" operating system--either in a virtual machine or on real hardware (though through Ventoy). It is clear very new, still heavy in development, still clearly nowhere near production ready, and my testing of it only confirms that. I have run into problems with booting, primarily in VMs, and on real hardware I had driver problems (specifically: not even the USB mouse I had hooked up to my laptop would work, I was restricted to the built in keyboard and trackpad). I don't remember if Wi-Fi worked or not, but by that point it doesn't even matter.
Honestly, I am far more interested in Serenity OS, but it currently runs in a KVM setup, with no way to install on real hardware yet. But it still feels more polished and I love its retro 90s style design on a UNIX-like base. Still, Redox is making some big strides and I hope to see them both become usable and installable on real hardware in the future. But for now... they're both nowhere near the point of even considering for real use on any system other than testing and as a hobby.
11 • Redox (by Kazlu on 2024-10-07 08:42:49 GMT from France)
The concepts are really interesting, and the fact that several devs have joined confirms that there is potential here. Of course, hardware compatibility will be a problem for a long time, considering it is still regularly a problem even for Linux... But I think Redox may not be so far from being usable in some niche cases. If one can run Redox in a container within GNU/Linux or a BSD and Redox supports a portable package format like Nix, this can be a real bonus for security by isolation. I think this may peak the interest of projects like Qubes OS in particular.
I voted that I have no plan to try it (yet), because I do not have the time to dig in a project in such an early stage of developpement. But I will definitely keep an eye on it.
12 • Works on VM, but on Hardware is a bit frustrating (by Will on 2024-10-07 09:09:29 GMT from United States)
It's pretty experimental in my view. I have a lot of commodity and modern hardware lying around and although I got it working, it required a bit of this and a bit of that to get a workable system. I got really frustrated with keyboard, trackpad and wifi.
Maybe if the devs would target something like a reasonably recent laptop configuration it'd get more interesting.
Once it's up and running, it doesn't take long to figure out "what it does" and what it does is run apps and such. The interface is fine, but I got bored pretty quick. I'm looking forward to a future release that isn't quite so much work to get working that supports a more standard configuration of hardware - I don't mind cobbling stuff together, but I really want the built in keyboard to work on my laptop :).
13 • Static linking (by Tom on 2024-10-07 09:53:15 GMT from Belgium)
@7 "Bandwidth is also not really an issue if Delta updates are used to update the static packages. No need to download the whole package, only the changes. Whether or not that is fully implemented is something I am not sure of. I did find some posts about flatpacks supporting delta updates in Fedora from 2020"
Even if binaries depending on an updated library could be efficiently patched, it would require more energy to do so, and it would still be necessary to update *all* the binaries relying on that library. The other problem is the inter-dependencies of the libraries themselves, which would make any update trigger a ripple effect through all the libraries, and through all the binaries depending on them, possibly several times.
It's a huge waste of bandwidth, disk space, memory, and energy. And that's on top of the security issues mentioned earlier, and possibly the missed opportunity of optimized libraries for a specific architecture.
The concept is as flawed as the one of universal packages, if not more.
14 • These really don't want Linux to get more popular. (by Aetherlina on 2024-10-07 09:54:56 GMT from Czechia)
"Unified package manager is a recipe for disaster, used by lazy developers/maintainers to avoid having to repackage/support their native package format, update software and to address code review and security issues properly."
Says for itself.
15 • Universal (by Jesse on 2024-10-07 10:25:45 GMT from Canada)
@4: "So what does a unified package management do exactly behind the scene? The description sounds like nothing more than a wrapper/alias for various (traditional) package managers"
Yes, this is accurate.
"I used to consider it as a universal converter which would translate different types of package"
No, not at all. That would be a converter or package translator, like Alien. It is a completely different class of utility.
16 • Universal package managers (UPM) (by DachshundMan on 2024-10-07 10:46:47 GMT from United Kingdom)
I try not to use universal packages as I consider them to be software bloat and I do not need that on an old computer like mine (7th gen i5). However, there are a few programs that are not available in deb format and which I need so I do use a few. In that case they need to be kept secure and I like the idea of the updating being done by one UPM.
I think that those who mention "lazy developers" are doing a big disservice to the many developers who spend a lot of time packaging programs. It is likely that 80% of the users will use 20% of the distros so if your development time is limited then it makes sense package for only the widely used distributions and then make a universal package for the rest.
What would be good is to somehow be able to verify that the universal packages are "safe" which is part of what the packagers at, for example, Mint do
17 • redoxOS (by rhtoras on 2024-10-07 10:52:55 GMT from Greece)
The good thing with redox os is it does not contain systemD. The bad thing is it relies fully on rust language. I won't dive deeper into this but rust i a controversial topic. It relies fully is the problem not rust itself. It is not usable yet. What is to be considered is pkg. PKG already exists and i am not sure if it is the same package manager modified to run on redox. Using the exact same name (as on freebsd or open indiana) might be a problem. If we talk for the same pkg package manager then it's fine. A good package manager imho with a lot software if someone uses pkg_src ports etc fro bsd/illumos unix.
Thanks for the review Jesse...
18 • Linux freezing, IP6 problem, solution? (by Jan on 2024-10-07 11:17:09 GMT from The Netherlands)
I encountered Linux freezing at different distro-testing rather often.
Possibly the reason and a solution:
https://www.dedoimedo.com/computers/linux-kernel-network-ipv6-problem.html
19 • Redox opinion p. (by Europe on 2024-10-07 13:24:11 GMT from Germany)
I have downl. Redox the live ISO (1.6 GB)
Started it with Gnome Boxes. The boot script did its
Calculation to the middle of the Screen. Then it,
was hanging on one spot for like 15 Min. Never finied..
It's boot calculation. Doing something for ever.
I forced shutdown option.. GBoxes off. Deleted the ISO.
The End. Thank You.
20 • Appimage, snap, flatpak (by Orlando on 2024-10-07 13:48:01 GMT from Italy)
@14
I would say: "Appimage, Snap and Flatpak are a recipe for disaster, used by lazy developers/maintainers to avoid having to repackage/support their native package format, update software and to address code review and security issues properly."
I hope more Linux distributions come out that don't use this garbage.
21 • Redox (by Robert on 2024-10-07 16:50:56 GMT from United States)
I am interested in trying Redox - eventually. They have good ideas and I'm interested in how far they can take them. Hopefully they end up with a real competitor.
But for now, regardless of any other issues I don't see an OS that doesn't even support USB as even worth trying.
The desktop is their own custom thing called Orbital. Used to also have its own utility applications before porting the COSMIC ones. I believe the eventual plan is to bring over COSMIC in its entirety and drop their bespoke solution.
22 • Some other advantages of universal packages (by vw72 on 2024-10-07 18:22:40 GMT from United States)
I tend to run Gnome as my desktop, but there are a few KDE apps that I regularly use, such as Blender. Running Blender from a flatpak keeps the rest of my system "clean" from having all of the kde and qt dependencies being installed throughout my system. The downside is that it can take up more disk space, but that is usually not a problem for me.
I also am interested in the immutable OSs that Fedora and openSUSE are working on. In these systems, the core system is unchangeable (until the user specifically updates it) and most apps are run as flatpaks. While not everyone will have a use case requiring an immutable system, if you do, then these two projects are definitely exciting.
Another advantage to at least flatpaks and appimage (and possibly snaps, although I don't use them, so I don't know), is that if the computer is shared among family members or coworks, these applications can be installed in the user's home directory versus universally being available. While there are ways to restrict rpm and deb applications to specific users, installing a flatpak or appimage to a home directory is a lot quicker and simpler.
Finally, flatpaks and appimages often have more recent versions of software than what is in a distro's repo. Run a long term release and want the latest libreOffice, flathub will have it. Have a 3d printer and want the latest Cura? Ubuntu is still on version 4.13 while flathub has the latest.
Are flatpaks and these others perfect? No, they can always be improved. But they sure can be convenient depending on your use case.
23 • Unified package management vs universal package formats (by Vukota on 2024-10-07 22:02:13 GMT from Serbia)
To quote myself
"Unified package manager is a recipe for disaster, used by lazy developers/maintainers to avoid having to repackage/support their native package format, update software and to address code review and security issues properly."
Which part of this was incorrect? Recipe for disaster is that unified "package manager" (doesn't matter what kind of package format it combines) is combining parts that are not meant to work together. It allows you this, so that you don't need to "buy" part (package) meant to work with rest of your system in intended/designed/tested/secured way, and thus is cheaper ("lazy maintainers" = cheap way to not get proper "part") to put together whole distribution and then claim that they have everything that you need.
Now, if you meant that it will make your life easier and your system up-to-date across these different origins, that may be true to a degree, but it is still negative that it is masking all underlying problems with it by making you think you are safe and good.
"I know Flatpaks/Snaps/AppImages have their own "good" sides, but it still comes down to my first conclusion."
Which part of this was incorrect? Usually, though not always, unified "package manager" will mix some more or less "native" packages (in different formats) with packages in Flatpaks/Snaps/AppImages format and reasoning here is exactly the same why "Unified package manager" exists in the first place (so that maintainers don't have to repackage all dependencies in their native format that has shared components with other packages and that they don't have to review the code at all). Only different approach here with in example Flatpacks is that there is a sand-boxing that is supposed to protect you "on paper" (but not reality) from some types of malicious attacks. So in short, nothing here is mixed up.
24 • Universal package manager (by Vinfall on 2024-10-08 01:38:34 GMT from Hong Kong)
@15: Thanks for the clarification, Jesse. After checking the source code of rhino-pkg, I think for now it's still a dream sounds too good to be true :( Pacscript (Pacstall package template) is also a bit complicated due to its blending nature.
By the way, I recall using alien back in the days when I use Debian stable and backport cannot satisfy my need. Forgot the name for a long time and good to know that!
25 • Redox OS (by rednex on 2024-10-09 00:23:25 GMT from United Kingdom)
Most alternative OSs have restrictions and eccentricities.
Redox OS has no restrictions. It is aimed at being a replacement for Linux / BSD: It can port Linux apps. it is led by a software engineer who already works on a Linux OS.
So as long as they don't get too obsessed with Rust, they should be able to overtake other alternative OSs and become a new desktop force.
26 • Redox (by penguinx86 on 2024-10-09 14:09:15 GMT from United States)
Redox sounds like a work in progress. Not ready for prime time. I'll stick with more mainstream distros like Mint, Debian or Fedora that will be around for a while and are reasonably well supported.
27 • Redox OS, BSD (by Otis on 2024-10-09 16:20:04 GMT from United States)
Both Redox OS and BSD have something important in common: They've been around long enough to be fully developed, and successful. Of course, many fully developed Linux distros have come and gone, so perhaps we should leave out successful in our remarks about these projects, even though there are dozens of very successful Linux distros.
Redox OS was begun in 2015, and BSD in 1978. So 46 years of BSD development and testing and bug reports etc has still not produced an OS that very many users want, need, can rely upon, etc. And 19 years of the same from Redox OS.
I'm sure there is a long list of real good reasons for each of those projects to be where they are, perhaps a short list of reasons, I don't know.
Are we stating the obvious or misrepresenting to observe that what Linus Torvalds uncorked was the needed response to Microsoft (and Apple)? And not BSD? And likely not this Redox OS (well intentioned) micro-kernel project?
28 • Lots of 2c-worth ends up being far less than the sum of its paths (by Jeff on 2024-10-09 20:17:17 GMT from Australia)
It's staggering to me that Jesse can put forward such a well nuanced piece, so succinctly, about explaining package management, then other (ab)users chime in with almost silly oneliners that _sound_ devoid of thought and riddled with prejudice.
Jesse, I am one of your many admirers who are constantly amazed by your patience, courtesy, knowledge and expressiveness. Long may your words and example live.....
29 • redox (by rednex on 2024-10-09 23:04:22 GMT from United Kingdom)
@27 "Redox OS was begun in 2015, and BSD in 1978. So 46 years of BSD development and 19 years of the same from Redox OS."
That's 9 years for Redox - not 19 - on a part-time basis. That's not bad when you're using an evolving (Rust) language.
BSD has always been focused on correctness of code. FreeBSD is only now wanting to include more hardware driver support. ReactOS and Haiku are around 20+ years old. They are restricted by compliance to legacy systems. Minix was aimed at an educational audience. Menuet and Collobri OSs are small, assembly language efforts. Serenity OS is for developers, not users. Sky and Syllable OSs got closest to being usable desktops, but they had developer problems.
In OS development it's the attitude that counts. And Redox devs seem to have the right attitude of aiming at being a desktop challenger without restrictions. So it should be able to progress further than other efforts.
30 • redox, @29 (by Wally on 2024-10-10 02:37:10 GMT from Australia)
"In OS development it's the attitude that counts." I beg to differ. What counts is the competence of the developers and the quality and usefulness of the product.
"a desktop challenger without restrictions. So it should be able to progress further than other efforts." Perhaps, but I won't hold my breath. BSD is successful, competent and useful in it's niche. If it's held back, it's not because of concentration on 'correctness of code'. In a FOSS forum, it's the proverbial elephant in the room: money. Developers need to eat and have families to feed. If BSD gets a few hundred thousand dollars from some deep pocketed entity, they're ecstatic. Meanwhile, Linus Torvalds alone gets a 1.5 million salary, give or take. That's not to mention the contributions by IBM/Red Hat, Microsoft (Yes, Microsoft!) and a bunch of other really deep pockets via employing developers and The Linux Foundation.
But even with all that support, in the desktop universe, Linux is still somewhat of a niche product. Not that I mind. I enjoy Linux and wish redox well, but I'm currently in Australia, not fantasyland.
31 • Niche/successful projects (by Kazlu on 2024-10-10 10:11:09 GMT from France)
"But even with all that support, in the desktop universe, Linux is still somewhat of a niche product."
Absolutely not. Linux is used in many more machines than Windows now. The catch is that is is way less visible, because the very large majority of those machines are not desktop computers... Linux is indeed a niche product in the desktop computer market, but that's it. And big investors like Micrsoft and especially Google invest more towards the server/embedded scope for Linux than for the desktop scope. And then, if you factor in Android (which uses the Linux kernel but is not a GNU/Linux distribution), that goes even wider and you are really close from a "desktop".
BSD also has, to my knowledge, a wider niche in the server department than in the desktop department.
Anyway, your point still stands: money is indeed a big driver for OS development. But it's not surprising that the big investments in Linux are not all geared towards desktop features and wider Linux desktop adoption.
32 • Niche/successful products, @31 (by Wally on 2024-10-10 10:43:22 GMT from Australia)
@31, Huh?
Me: "in the desktop universe, Linux is still somewhat of a niche product."
You: "Absolutely not. . . . Linux is indeed a niche product in the desktop computer market,"
Are you agreeing? Disagreeing? Contradicting yourself?
33 • @32 Niche/successful products (by Kazlu on 2024-10-10 12:34:35 GMT from France)
Wow, really sorry about that, I completely overlooked that you *did* mention "desktop" in your last comment... I messed up, simple as that.
I can still say that a lot of the Linux support goes more towards servers and embedded systems than desktop, but certainly not in the way I put it. Sorry again.
34 • Oops, hello... (by Otis on 2024-10-10 15:46:40 GMT from United States)
@29Nine years, not 19 as I stated.
But that still for one new project like that seems long. Nit-picking I guess. My main qualm with Redox OS is that it seems futile as we've seen robust kernel and overall distro(s) development in the Linux world. Have fun with microkernel, okay.
That you report about BSD comes from a learned mind about such things (to me anyway). But again, it seems like that effort and the overall project itself is more a labor of love for the old days or whatever than a genuine realistic endeavor to cause BSD to be a neck-and-neck alternative to Linux for the masses.
I have noticed that the shortcomings of GhostBSD, for example, are FreeBSD's shortcomings largely. And that causes us to notice that Linux has not those shortcomings, as a kernel and driver support, etc. Yes, one can encounter those shortcomings if one is inclined to distro hop; there are distros out there that make some new users scurry back to Windows or Mac. But we all know that good, popular, polished Linux distros are what Linux is about now days, and that one can never have to look back once "your" disto is on that machine you work and/or play on.
35 • unified PM and universal package formats (by JR on 2024-10-11 01:39:06 GMT from Brazil)
Well, first of all, I appreciate Unix principles, especially the clear separation between libraries and the executable software. However, I have some opinions about unified package managers and universal package formats.
It seems to me that unified package managers will exacerbate the dependency hell, beyond any other potential issue. It's like installing Arch packages with pacman, Debian packages with apt, SUSE packages with zipper, Fedora packages with dnf, Flatpak packages with flatpak, and Snap packages with snap, all within the same distribution.
Even with a single package format and manager, you can still encounter unresolved dependencies. So, what do you think about using various package managers with various package formats? A unified package manager is essentially a frontend to all supported package managers.
Therefore, there's a high chance of ending up with a broken distribution without a solution. This is not for me.
But I think universal package formats have potential. They could become the application format for distributions, separate from the operating system itself. This would allow for independent updates, similar to BSD. I don't see this as a problem.
For example, elementary OS uses this approach. It can be very stable if you avoid mixing multiple package formats. You can use one format for the OS (the traditional way) and another format for applications.
In elementary OS, you have apt updating the system and flatpak updating applications. This can work very well and may become the standard for many distributions.
It simplifies the distribution maintenance.
What do you all think?
36 • Unified package management (by Jesse on 2024-10-11 12:37:18 GMT from Canada)
@35: " So, what do you think about using various package managers with various package formats? A unified package manager is essentially a frontend to all supported package managers.
Therefore, there's a high chance of ending up with a broken distribution without a solution. This is not for me."
Yes, unified package managers are front-ends for other package managers/formats. No, there is not an increase in chance of dependency issues. How could there be? When you install a package from, for example, a Deb archive, it's pulling in the software and its dependencies from the Deb archive. When you install a Flatpak it has all of its dependencies built in. When you install something from Pacstall, it pulls its dependencies from Pacstall.
A unified package manager isn't going to pull in an application from one repository and a dependency from another repository, because that's not how the underlying package managers work. The unified package manager is just a front-end to what the underlying package managers do, it doesn't mix and match packages from the underlying repositories.
37 • @36 (by JR on 2024-10-11 23:13:10 GMT from Brazil)
First of all, thank you for responding, I'm honored to talk to a person with so much knowledge and expertise.
So, I think my English is really bad, because that's not what I intended to say at all.
Let's see if I can explain myself.
II'm imagining that if you use a single package manager with a single type of packages, you may have unresolved dependencies (traditional distributions).
and when you mix other package managers with other types of packages in the same distribution (even though each one pulls the packages from their own sources), the chances of unresolved dependencies increase, not because they mix, but for numerical reasons, you may have for example apt with unresolved dependencies (although it is rare) and another package manager with unresolved dependencies.
not because they got mixed up, but because instead of one, there are two, just for that reason, it increases the chances of an error happening, simply by having two package managers, and not just one, it's a matter of statistics. Obviously the two will not mix, these are things that will happen concidentally, occasionally.
If you only use one PM, you have a chance of having problems with dependencies, if you use two, the chances increase, because there are two, not one.
Furthermore, what do you think would happen if you could use each one independently, and install the same software, on the same system, with two different PMs, each with its own source?
I really don't know if it would be possible, just guessing that if several package managers are installed, why couldn't we use each one separately?
38 • Unified package managers (by Jesse on 2024-10-11 23:27:40 GMT from Canada)
@37: I see what you are saying, about using more package managers could, in theory, result in more problems. And that makes a certain amount of sense. If one piece of software has N number of issues than three separate pieces of software might be expected to have 3xN issues.
However, it should be very very rare, if it ever happens, that you run into dependency issues with official repositories or portable packages. I'm not saying it's impossible, but it's highly unlikely, especially in stable/static distributions. For a package to make it into Debian Stable, Ubuntu, or RHEL (as a few examples) it needs to go through a lot of testing and should not make it through to user-facing repositories if it has any dependency issues.
In theory a dependency might sneak through all the QA, maybe on a rapid-fire rolling release distribution, but practically it's unlikely.
For that matter, portable packages like Snap and Flatpak don't have external dependencies (apart from systemd for Snaps) so they can't increase the number of possible dependency issues.
"Furthermore, what do you think would happen if you could use each one independently, and install the same software, on the same system, with two different PMs, each with its own source?"
You end up with two entries in the application menu. Portable packages install in different locations from classic packages so there is no conflict. Third-party repositories (AUR and Pacstall) usually don't allow conflicts with the parent distro, or require a different install name/location, so there is no conflict between files/versions.
39 • @38 (by JR on 2024-10-12 00:07:43 GMT from Brazil)
"You end up with two entries in the application menu. Portable packages install in different locations from classic packages so there is no conflict. Third-party repositories (AUR and Pacstall) usually don't allow conflicts with the parent distro, or require a different install name/location, so there is no conflict between files/versions."
I mean in relation to the simultaneous use of traditional PMs, for example, apt will install Firefox in certain directories, right? What if we install it on the same system, the same Firefox, but with Pacman for example?
I understand you when you say that there would be no problems mixing the traditional method with snaps or flatpaks, as these have their own location with all the files embedded, but two traditional PMs would theoretically install in the same directories....
Then you uninstall with one PM, and the other still computes as installed, and theoretically it would also try to update a package that was removed...
It seems like a huge mess to me
it would be necessary not to allow the independent use of PMs, as the frontend would have to deal with these situations, not allowing it to happen, I think
40 • Unified package managers (by Jesse on 2024-10-12 03:27:40 GMT from Canada)
@39: "I mean in relation to the simultaneous use of traditional PMs, for example, apt will install Firefox in certain directories, right? What if we install it on the same system, the same Firefox, but with Pacman for example?"
You don't. Or can't. Even with unified package managers, you don't run two classic package managers on the same system. The packages which you'd get from a Pacman repository (for Arch, for example) would be no good to someone running a Debian-based system with APT. There aren't any situations where unified package managers use multiple classic package managers.
This is why there is no risk, the unified package manager isn't just accessing packages from different sources, it is also dealing with different _types_ of packages. This generally goes in layers. For instance, Deb pacakges, Snap, and Pacstall. Or RPM, Flatpak, and Nix. You never see unified package managers try to mix Deb, RPM, and Pacman.
"I mean in relation to the simultaneous use of traditional PMs, for example, apt will install Firefox in certain directories, right? What if we install it on the same system, the same Firefox, but with Pacman for example?"
This is one of those situations that can't happen because it would require mixing two traditional package managers, which doesn't happen. The worse or most confusing case you'd run into would be installing Firefox through Deb and then again through Flatpak, which use different locations.
"Then you uninstall with one PM, and the other still computes as installed, and theoretically it would also try to update a package that was removed..."
This doesn't/can't happen as well because different package managers don't share the same package database.
Number of Comments: 40
Display mode: DWW Only • Comments Only • Both DWW and Comments
| | |
| TUXEDO |
TUXEDO Computers - Linux Hardware in a tailor made suite
Choose from a wide range of laptops and PCs in various sizes and shapes at TUXEDOComputers.com. Every machine comes pre-installed and ready-to-run with Linux. Full 24 months of warranty and lifetime support included!
Learn more about our full service package and all benefits from buying at TUXEDO.
|
| Archives |
| • Issue 1151 (2025-12-08): FreeBSD 15.0, fun command line tricks, Canonical presents plans for Ubutnu 26.04, SparkyLinux updates CDE packages, Redox OS gets modesetting driver |
| • Issue 1150 (2025-12-01): Gnoppix 25_10, exploring if distributions matter, openSUSE updates tumbleweed's boot loader, Fedora plans better handling of broken packages, Plasma to become Wayland-only, FreeBSD publishes status report |
| • Issue 1149 (2025-11-24): MX Linux 25, why are video drivers special, systemd experiments with musl, Debian Libre Live publishes new media, Xubuntu reviews website hack |
| • Issue 1148 (2025-11-17): Zorin OS 18, deleting a file with an unusual name, NetBSD experiments with sandboxing, postmarketOS unifies its documentation, OpenBSD refines upgrades, Canonical offers 15 years of support for Ubuntu |
| • Issue 1147 (2025-11-10): Fedora 43, the size and stability of the Linux kernel, Debian introducing Rust to APT, Redox ports web engine, Kubuntu website off-line, Mint creates new troubleshooting tools, FreeBSD improves reproducible builds, Flatpak development resumes |
| • Issue 1146 (2025-11-03): StartOS 0.4.0, testing piped commands, Ubuntu Unity seeks help, Canonical offers Ubuntu credentials, Red Hat partners with NVIDIA, SUSE to bundle AI agent with SLE 16 |
| • Issue 1145 (2025-10-27): Linux Mint 7 "LMDE", advice for new Linux users, AlmaLinux to offer Btrfs, KDE launches Plasma 6.5, Fedora accepts contributions written by AI, Ubuntu 25.10 fails to install automatic updates |
| • Issue 1144 (2025-10-20): Kubuntu 25.10, creating and restoring encrypted backups, Fedora team debates AI, FSF plans free software for phones, ReactOS addresses newer drivers, Xubuntu reacts to website attack |
| • Issue 1143 (2025-10-13): openSUSE 16.0 Leap, safest source for new applications, Redox introduces performance improvements, TrueNAS Connect available for testing, Flatpaks do not work on Ubuntu 25.10, Kamarada plans to switch its base, Solus enters new epoch, Frugalware discontinued |
| • Issue 1142 (2025-10-06): Linux Kamarada 15.6, managing ZIP files with SQLite, F-Droid warns of impact of Android lockdown, Alpine moves ahead with merged /usr, Cinnamon gets a redesigned application menu |
| • Issue 1141 (2025-09-29): KDE Linux and GNOME OS, finding mobile flavours of Linux, Murena to offer phones with kill switches, Redox OS running on a smartphone, Artix drops GNOME |
| • Issue 1140 (2025-09-22): NetBSD 10.1, avoiding AI services, AlmaLinux enables CRB repository, Haiku improves disk access performance, Mageia addresses service outage, GNOME 49 released, Linux introduces multikernel support |
| • Issue 1139 (2025-09-15): EasyOS 7.0, Linux and central authority, FreeBSD running Plasma 6 on Wayland, GNOME restores X11 support temporarily, openSUSE dropping BCacheFS in new kernels |
| • Issue 1138 (2025-09-08): Shebang 25.8, LibreELEC 12.2.0, Debian GNU/Hurd 2025, the importance of software updates, AerynOS introduces package sets, postmarketOS encourages patching upstream, openSUSE extends Leap support, Debian refreshes Trixie media |
| • Issue 1137 (2025-09-01): Tribblix 0m37, malware scanners flagging Linux ISO files, KDE introduces first-run setup wizard, CalyxOS plans update prior to infrastructure overhaul, FreeBSD publishes status report |
| • Issue 1136 (2025-08-25): CalyxOS 6.8.20, distros for running containers, Arch Linux website under attack,illumos Cafe launched, CachyOS creates web dashboard for repositories |
| • Issue 1135 (2025-08-18): Debian 13, Proton, WINE, Wayland, and Wayback, Debian GNU/Hurd 2025, KDE gets advanced Liquid Glass, Haiku improves authentication tools |
| • Issue 1134 (2025-08-11): Rhino Linux 2025.3, thoughts on malware in the AUR, Fedora brings hammered websites back on-line, NetBSD reveals features for version 11, Ubuntu swaps some command line tools for 25.10, AlmaLinux improves NVIDIA support |
| • Issue 1133 (2025-08-04): Expirion Linux 6.0, running Plasma on Linux Mint, finding distros which support X11, Debian addresses 22 year old bug, FreeBSD discusses potential issues with pkgbase, CDE ported to OpenBSD, Btrfs corruption bug hitting Fedora users, more malware found in Arch User Repository |
| • Issue 1132 (2025-07-28): deepin 25, wars in the open source community, proposal to have Fedora enable Flathub repository, FreeBSD plans desktop install option, Wayback gets its first release |
| • Issue 1131 (2025-07-21): HeliumOS 10.0, settling on one distro, Mint plans new releases, Arch discovers malware in AUR, Plasma Bigscreen returns, Clear Linux discontinued |
| • Issue 1130 (2025-07-14): openSUSE MicroOS and RefreshOS, sharing aliases between computers, Bazzite makes Bazaar its default Flatpak store, Alpine plans Wayback release, Wayland and X11 benchmarked, Red Hat offers additional developer licenses, openSUSE seeks feedback from ARM users, Ubuntu 24.10 reaches the end of its life |
| • Issue 1129 (2025-07-07): GLF OS Omnislash, the worst Linux distro, Alpine introduces Wayback, Fedora drops plans to stop i686 support, AlmaLinux builds EPEL repository for older CPUs, Ubuntu dropping existing RISC-V device support, Rhino partners with UBports, PCLinuxOS recovering from website outage |
| • Issue 1128 (2025-06-30): AxOS 25.06, AlmaLinux OS 10.0, transferring Flaptak bundles to off-line computers, Ubuntu to boost Intel graphics performance, Fedora considers dropping i686 packages, SDesk switches from SELinux to AppArmor |
| • Issue 1127 (2025-06-23): LastOSLinux 2025-05-25, most unique Linux distro, Haiku stabilises, KDE publishes Plasma 6.4, Arch splits Plasma packages, Slackware infrastructure migrating |
| • Issue 1126 (2025-06-16): SDesk 2025.05.06, renewed interest in Ubuntu Touch, a BASIC device running NetBSD, Ubuntu dropping X11 GNOME session, GNOME increases dependency on systemd, Google holding back Pixel source code, Nitrux changing its desktop, EFF turns 35 |
| • Issue 1125 (2025-06-09): RHEL 10, distributions likely to survive a decade, Murena partners with more hardware makers, GNOME tests its own distro on real hardware, Redox ports GTK and X11, Mint provides fingerprint authentication |
| • Issue 1124 (2025-06-02): Picking up a Pico, tips for protecting privacy, Rhino tests Plasma desktop, Arch installer supports snapshots, new features from UBports, Ubuntu tests monthly snapshots |
| • Issue 1123 (2025-05-26): CRUX 3.8, preventing a laptop from sleeping, FreeBSD improves laptop support, Fedora confirms GNOME X11 session being dropped, HardenedBSD introduces Rust in userland build, KDE developing a virtual machine manager |
| • Issue 1122 (2025-05-19): GoboLinux 017.01, RHEL 10.0 and Debian 12 updates, openSUSE retires YaST, running X11 apps on Wayland |
| • Issue 1121 (2025-05-12): Bluefin 41, custom file manager actions, openSUSE joins End of 10 while dropping Deepin desktop, Fedora offers tips for building atomic distros, Ubuntu considers replacing sudo with sudo-rs |
| • Issue 1120 (2025-05-05): CachyOS 250330, what it means when a distro breaks, Kali updates repository key, Trinity receives an update, UBports tests directory encryption, Gentoo faces losing key infrastructure |
| • Issue 1119 (2025-04-28): Ubuntu MATE 25.04, what is missing from Linux, CachyOS ships OCCT, Debian enters soft freeze, Fedora discusses removing X11 session from GNOME, Murena plans business services, NetBSD on a Wii |
| • Issue 1118 (2025-04-21): Fedora 42, strange characters in Vim, Nitrux introduces new package tools, Fedora extends reproducibility efforts, PINE64 updates multiple devices running Debian |
| • Issue 1117 (2025-04-14): Shebang 25.0, EndeavourOS 2025.03.19, running applications from other distros on the desktop, Debian gets APT upgrade, Mint introduces OEM options for LMDE, postmarketOS packages GNOME 48 and COSMIC, Redox testing USB support |
| • Issue 1116 (2025-04-07): The Sense HAT, Android and mobile operating systems, FreeBSD improves on laptops, openSUSE publishes many new updates, Fedora appoints new Project Leader, UBports testing VoLTE |
| • Issue 1115 (2025-03-31): GrapheneOS 2025, the rise of portable package formats, MidnightBSD and openSUSE experiment with new package management features, Plank dock reborn, key infrastructure projects lose funding, postmarketOS to focus on reliability |
| • Issue 1114 (2025-03-24): Bazzite 41, checking which processes are writing to disk, Rocky unveils new Hardened branch, GNOME 48 released, generating images for the Raspberry Pi |
| • Issue 1113 (2025-03-17): MocaccinoOS 1.8.1, how to contribute to open source, Murena extends on-line installer, Garuda tests COSMIC edition, Ubuntu to replace coreutils with Rust alternatives, Chimera Linux drops RISC-V builds |
| • Issue 1112 (2025-03-10): Solus 4.7, distros which work with Secure Boot, UBports publishes bug fix, postmarketOS considers a new name, Debian running on Android |
| • Issue 1111 (2025-03-03): Orbitiny 0.01, the effect of Ubuntu Core Desktop, Gentoo offers disk images, elementary OS invites feature ideas, FreeBSD starts PinePhone Pro port, Mint warns of upcoming Firefox issue |
| • Issue 1110 (2025-02-24): iodeOS 6.0, learning to program, Arch retiring old repositories, openSUSE makes progress on reproducible builds, Fedora is getting more serious about open hardware, Tails changes its install instructions to offer better privacy, Murena's de-Googled tablet goes on sale |
| • Issue 1109 (2025-02-17): Rhino Linux 2025.1, MX Linux 23.5 with Xfce 4.20, replacing X.Org tools with Wayland tools, GhostBSD moving its base to FreeBSD -RELEASE, Redox stabilizes its ABI, UBports testing 24.04, Asahi changing its leadership, OBS in dispute with Fedora |
| • Issue 1108 (2025-02-10): Serpent OS 0.24.6, Aurora, sharing swap between distros, Peppermint tries Void base, GTK removinglegacy technologies, Red Hat plans more AI tools for Fedora, TrueNAS merges its editions |
| • Issue 1107 (2025-02-03): siduction 2024.1.0, timing tasks, Lomiri ported to postmarketOS, Alpine joins Open Collective, a new desktop for Linux called Orbitiny |
| • Issue 1106 (2025-01-27): Adelie Linux 1.0 Beta 6, Pop!_OS 24.04 Alpha 5, detecting whether a process is inside a virtual machine, drawing graphics to NetBSD terminal, Nix ported to FreeBSD, GhostBSD hosting desktop conference |
| • Issue 1105 (2025-01-20): CentOS 10 Stream, old Flatpak bundles in software centres, Haiku ports Iceweasel, Oracle shows off debugging tools, rsync vulnerability patched |
| • Issue 1104 (2025-01-13): DAT Linux 2.0, Silly things to do with a minimal computer, Budgie prepares Wayland only releases, SteamOS coming to third-party devices, Murena upgrades its base |
| • Issue 1103 (2025-01-06): elementary OS 8.0, filtering ads with Pi-hole, Debian testing its installer, Pop!_OS faces delays, Ubuntu Studio upgrades not working, Absolute discontinued |
| • Issue 1102 (2024-12-23): Best distros of 2024, changing a process name, Fedora to expand Btrfs support and releases Asahi Remix 41, openSUSE patches out security sandbox and donations from Bottles while ending support for Leap 15.5 |
| • Issue 1101 (2024-12-16): GhostBSD 24.10.1, sending attachments from the command line, openSUSE shows off GPU assignment tool, UBports publishes security update, Murena launches its first tablet, Xfce 4.20 released |
| • Issue 1100 (2024-12-09): Oreon 9.3, differences in speed, IPFire's new appliance, Fedora Asahi Remix gets new video drivers, openSUSE Leap Micro updated, Redox OS running Redox OS |
| • Full list of all issues |
| Star Labs |
Star Labs - Laptops built for Linux.
View our range including the highly anticipated StarFighter. Available with coreboot open-source firmware and a choice of Ubuntu, elementary, Manjaro and more. Visit Star Labs for information, to buy and get support.
|
| Random Distribution | 
JBLinux
JBLinux was a Linux distribution designed primarily for security and performance, as well as aiming to provide the end-user with up-to-date high quality software. All packages are optimized for Pentium-class CPUs.
Status: Discontinued
|
| TUXEDO |
TUXEDO Computers - Linux Hardware in a tailor made suite
Choose from a wide range of laptops and PCs in various sizes and shapes at TUXEDOComputers.com. Every machine comes pre-installed and ready-to-run with Linux. Full 24 months of warranty and lifetime support included!
Learn more about our full service package and all benefits from buying at TUXEDO.
|
| Star Labs |
Star Labs - Laptops built for Linux.
View our range including the highly anticipated StarFighter. Available with coreboot open-source firmware and a choice of Ubuntu, elementary, Manjaro and more. Visit Star Labs for information, to buy and get support.
|
|
• 
• 
• 
• 
• 
• 
• 
