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 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 |
• Issue 1099 (2024-12-02): AnduinOS 1.0.1, measuring RAM usage, SUSE continues rebranding efforts, UBports prepares for next major version, Murena offering non-NFC phone |
• Issue 1098 (2024-11-25): Linux Lite 7.2, backing up specific folders, Murena and Fairphone partner in fair trade deal, Arch installer gets new text interface, Ubuntu security tool patched |
• Issue 1097 (2024-11-18): Chimera Linux vs Chimera OS, choosing between AlmaLinux and Debian, Fedora elevates KDE spin to an edition, Fedora previews new installer, KDE testing its own distro, Qubes-style isolation coming to FreeBSD |
• Issue 1096 (2024-11-11): Bazzite 40, Playtron OS Alpha 1, Tucana Linux 3.1, detecting Screen sessions, Redox imports COSMIC software centre, FreeBSD booting on the PinePhone Pro, LXQt supports Wayland window managers |
• Issue 1095 (2024-11-04): Fedora 41 Kinoite, transferring applications between computers, openSUSE Tumbleweed receives multiple upgrades, Ubuntu testing compiler optimizations, Mint partners with Framework |
• Issue 1094 (2024-10-28): DebLight OS 1, backing up crontab, AlmaLinux introduces Litten branch, openSUSE unveils refreshed look, Ubuntu turns 20 |
• Issue 1093 (2024-10-21): Kubuntu 24.10, atomic vs immutable distributions, Debian upgrading Perl packages, UBports adding VoLTE support, Android to gain native GNU/Linux application support |
• Issue 1092 (2024-10-14): FunOS 24.04.1, a home directory inside a file, work starts of openSUSE Leap 16.0, improvements in Haiku, KDE neon upgrades its base |
• Issue 1091 (2024-10-07): Redox OS 0.9.0, Unified package management vs universal package formats, Redox begins RISC-V port, Mint polishes interface, Qubes certifies new laptop |
• Issue 1090 (2024-09-30): Rhino Linux 2024.2, commercial distros with alternative desktops, Valve seeks to improve Wayland performance, HardenedBSD parterns with Protectli, Tails merges with Tor Project, Quantum Leap partners with the FreeBSD Foundation |
• Issue 1089 (2024-09-23): Expirion 6.0, openKylin 2.0, managing configuration files, the future of Linux development, fixing bugs in Haiku, Slackware packages dracut |
• Issue 1088 (2024-09-16): PorteuX 1.6, migrating from Windows 10 to which Linux distro, making NetBSD immutable, AlmaLinux offers hardware certification, Mint updates old APT tools |
• Issue 1087 (2024-09-09): COSMIC desktop, running cron jobs at variable times, UBports highlights new apps, HardenedBSD offers work around for FreeBSD change, Debian considers how to cull old packages, systemd ported to musl |
• Issue 1086 (2024-09-02): Vanilla OS 2, command line tips for simple tasks, FreeBSD receives investment from STF, openSUSE Tumbleweed update can break network connections, Debian refreshes media |
• Issue 1085 (2024-08-26): Nobara 40, OpenMandriva 24.07 "ROME", distros which include source code, FreeBSD publishes quarterly report, Microsoft updates breaks Linux in dual-boot environments |
• Issue 1084 (2024-08-19): Liya 2.0, dual boot with encryption, Haiku introduces performance improvements, Gentoo dropping IA-64, Redcore merges major upgrade |
• Issue 1083 (2024-08-12): TrueNAS 24.04.2 "SCALE", Linux distros for smartphones, Redox OS introduces web server, PipeWire exposes battery drain on Linux, Canonical updates kernel version policy |
• Issue 1082 (2024-08-05): Linux Mint 22, taking snapshots of UFS on FreeBSD, openSUSE updates Tumbleweed and Aeon, Debian creates Tiny QA Tasks, Manjaro testing immutable images |
• Issue 1081 (2024-07-29): SysLinuxOS 12.4, OpenBSD gain hardware acceleration, Slackware changes kernel naming, Mint publishes upgrade instructions |
• Issue 1080 (2024-07-22): Running GNU/Linux on Android with Andronix, protecting network services, Solus dropping AppArmor and Snap, openSUSE Aeon Desktop gaining full disk encryption, SUSE asks openSUSE to change its branding |
• Issue 1079 (2024-07-15): Ubuntu Core 24, hiding files on Linux, Fedora dropping X11 packages on Workstation, Red Hat phasing out GRUB, new OpenSSH vulnerability, FreeBSD speeds up release cycle, UBports testing new first-run wizard |
• Issue 1078 (2024-07-08): Changing init software, server machines running desktop environments, OpenSSH vulnerability patched, Peppermint launches new edition, HardenedBSD updates ports |
• Issue 1077 (2024-07-01): The Unity and Lomiri interfaces, different distros for different tasks, Ubuntu plans to run Wayland on NVIDIA cards, openSUSE updates Leap Micro, Debian releases refreshed media, UBports gaining contact synchronisation, FreeDOS celebrates its 30th anniversary |
• Issue 1076 (2024-06-24): openSUSE 15.6, what makes Linux unique, SUSE Liberty Linux to support CentOS Linux 7, SLE receives 19 years of support, openSUSE testing Leap Micro edition |
• Issue 1075 (2024-06-17): Redox OS, X11 and Wayland on the BSDs, AlmaLinux releases Pi build, Canonical announces RISC-V laptop with Ubuntu, key changes in systemd |
• Issue 1074 (2024-06-10): Endless OS 6.0.0, distros with init diversity, Mint to filter unverified Flatpaks, Debian adds systemd-boot options, Redox adopts COSMIC desktop, OpenSSH gains new security features |
• Issue 1073 (2024-06-03): LXQt 2.0.0, an overview of Linux desktop environments, Canonical partners with Milk-V, openSUSE introduces new features in Aeon Desktop, Fedora mirrors see rise in traffic, Wayland adds OpenBSD support |
• Issue 1072 (2024-05-27): Manjaro 24.0, comparing init software, OpenBSD ports Plasma 6, Arch community debates mirror requirements, ThinOS to upgrade its FreeBSD core |
• Issue 1071 (2024-05-20): Archcraft 2024.04.06, common command line mistakes, ReactOS imports WINE improvements, Haiku makes adjusting themes easier, NetBSD takes a stand against code generated by chatbots |
• Issue 1070 (2024-05-13): Damn Small Linux 2024, hiding kernel messages during boot, Red Hat offers AI edition, new web browser for UBports, Fedora Asahi Remix 40 released, Qubes extends support for version 4.1 |
• Issue 1069 (2024-05-06): Ubuntu 24.04, installing packages in alternative locations, systemd creates sudo alternative, Mint encourages XApps collaboration, FreeBSD publishes quarterly update |
• Issue 1068 (2024-04-29): Fedora 40, transforming one distro into another, Debian elects new Project Leader, Red Hat extends support cycle, Emmabuntus adds accessibility features, Canonical's new security features |
• Issue 1067 (2024-04-22): LocalSend for transferring files, detecting supported CPU architecure levels, new visual design for APT, Fedora and openSUSE working on reproducible builds, LXQt released, AlmaLinux re-adds hardware support |
• Issue 1066 (2024-04-15): Fun projects to do with the Raspberry Pi and PinePhone, installing new software on fixed-release distributions, improving GNOME Terminal performance, Mint testing new repository mirrors, Gentoo becomes a Software In the Public Interest project |
• Issue 1065 (2024-04-08): Dr.Parted Live 24.03, answering questions about the xz exploit, Linux Mint to ship HWE kernel, AlmaLinux patches flaw ahead of upstream Red Hat, Calculate changes release model |
• Issue 1064 (2024-04-01): NixOS 23.11, the status of Hurd, liblzma compromised upstream, FreeBSD Foundation focuses on improving wireless networking, Ubuntu Pro offers 12 years of support |
• Issue 1063 (2024-03-25): Redcore Linux 2401, how slowly can a rolling release update, Debian starts new Project Leader election, Red Hat creating new NVIDIA driver, Snap store hit with more malware |
• Issue 1062 (2024-03-18): KDE neon 20240304, changing file permissions, Canonical turns 20, Pop!_OS creates new software centre, openSUSE packages Plasma 6 |
• Issue 1061 (2024-03-11): Using a PinePhone as a workstation, restarting background services on a schedule, NixBSD ports Nix to FreeBSD, Fedora packaging COSMIC, postmarketOS to adopt systemd, Linux Mint replacing HexChat |
• Issue 1060 (2024-03-04): AV Linux MX-23.1, bootstrapping a network connection, key OpenBSD features, Qubes certifies new hardware, LXQt and Plasma migrate to Qt 6 |
• Issue 1059 (2024-02-26): Warp Terminal, navigating manual pages, malware found in the Snap store, Red Hat considering CPU requirement update, UBports organizes ongoing work |
• Issue 1058 (2024-02-19): Drauger OS 7.6, how much disk space to allocate, System76 prepares to launch COSMIC desktop, UBports changes its version scheme, TrueNAS to offer faster deduplication |
• Issue 1057 (2024-02-12): Adelie Linux 1.0 Beta, rolling release vs fixed for a smoother experience, Debian working on 2038 bug, elementary OS to split applications from base system updates, Fedora announces Atomic Desktops |
• Issue 1056 (2024-02-05): wattOS R13, the various write speeds of ISO writing tools, DSL returns, Mint faces Wayland challenges, HardenedBSD blocks foreign USB devices, Gentoo publishes new repository, Linux distros patch glibc flaw |
• 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 | 
LBA-Linux
SOT Finnish Software Engineering Ltd. was established in Tampere, Finland in 1991. In addition to its offices in Finland, the company has subsidiaries in Scandinavia. SOT was actively involved in the development of the Linux operating system. The company offers solution, consultancy, maintenance and support services based on this expertise. As the maker of the most popular Linux distribution in Finland - SOT Linux - SOT has strong experience in Linux environments. The diverse software and system projects we have produced for our clients since 1991 have given us a solid track record in e.g. Linux, Windows, Mac and UNIX environments. Your systems are guaranteed to be maintained by professionals, using the latest available knowledge.
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.
|
|