 DistroWatch Weekly |
| Tip Jar |
If you've enjoyed this week's issue of DistroWatch Weekly, please consider sending us a tip.
(Tips this week: 1, value: US$4.79) |
|
|
|
 bc1qtede6f7adcce4kjpgx0e5j68wwgtdxrek2qvc4  lnurl1dp68gurn8ghj7ampd3kx2ar0veekzar0wd5xjtnrdakj7tnhv4kxctttdehhwm30d3h82unvwqhhxarpw3jkc7tzw4ex6cfexyfua2nr  86fA3qPTeQtNb2k1vLwEQaAp3XxkvvvXt69gSG5LGunXXikK9koPWZaRQgfFPBPWhMgXjPjccy9LA9xRFchPWQAnPvxh5Le paypal.me/distrowatchweekly • patreon.com/distrowatch |
|
| Linux Foundation Training |
|
| Reader Comments • Jump to last comment |
1 • AUR vs. the rest (by Linuxista on 2021-05-10 00:34:06 GMT from United States)
The answer to the Q & A failed to address why all other distros' methods of acquiring 3rd party software suck compared to the AUR.
2 • Third party (by DaveW on 2021-05-10 00:46:32 GMT from United States)
I use both PPA and AppImage. The choice depends on which is most convenient for the application.
3 • Third party software (by Martin on 2021-05-10 01:31:17 GMT from Czechia)
The majority of software provides RPM packages that I would use to install it. If not, I resort to installation from source.
4 • Ridiculously slow download for Jing (by RJA on 2021-05-10 01:48:08 GMT from United States)
"This eventually rose to eight seeders at 400kB/s, which is unusually slow compared to most free mirrors available these days." -Jesse
Ouch! That's like ADSL2 out in the boonies in 2007!
Heck, I feel frustration, even with a 12 Mb download rate, these days!
At least back in 2007, except for Windows ISOs, I normally wouldn't even be needing to download a 2 GB file.
Heck, I start feeling like shooting off my mouth when a Steam download drops to 200 Mb, LOL.
5 • AUR, Snap (by Romane on 2021-05-10 01:53:11 GMT from Australia)
Having used both AUR and Snap, have found both quite unsatisfactory.
In too many instances, in Arch and Arch-based distro's the packages either failed to install or if installed failed to run. Not being one with any interest in digging into internals, if it don't work it don't work and I will abandon it with a feeling of distrust.
As regards Snap, have yet to install a package from this source that actually works. Again, abandoned with a feeling of distrust.
Have tried AppImage with a majority level of success for the packages have tried, but AppImage does not carry my very limited needs, so no use to me.
Have not attempted any of the other sources of third-party software, so no comments.
My need for such third-party packages is quite minimal, but flatpak has proven to be reliable and consistent at all times for my needs.
R.
6 • @5, about Arch experiences (by RJA on 2021-05-10 02:03:52 GMT from United States)
I had a bad experience with Arch mirrors, when I last remember using Arch, which was in February, 2010, I had to play mirrorlist musical chairs, because one mirror randomly didn't have file X, while the second mirror I tried, had file Y, but not also file Z!
But yes, once I got the KDE installation to succeed, shortly after, I had a working desktop and it looked like things were well with the Intel graphics support. (GMA 3100 with a Pentium E2180) (socket 775, Conroe(65nm) )
Despite people disliking Gentoo, the same year, I had a working desktop with Gentoo. Love the Gentoo documentation!
7 • AUR scripts, vs the rest. (by Greg Zeng on 2021-05-10 02:06:41 GMT from Australia)
According to DistroWatch just now, there are another 22 operating systems, making 23 total that use the
> " ... unvetted repository supplied by third-parties ...".
In real life practice, it is much more difficult uncompiled source code, than using pre-compiled ready-to-run code.
1) Manjaro is perhaps the most popular of the Arch based systems. It makes AUR not so easy to use, preferring its own home compiled code.
2) "Unvetted AUR scripts" may not work well enough for every system.
3) Compiling AUR scripts works best if you have powerful hardware to process the many slow steps needed compiling raw source code.
4) Other open source, pre-compiled code is arguably better; updates, dependency problems resolved, themes & settings transferable, easy removal & error correction, etc.
5) Linux is still determining which "universal" application package might be a winner, with the best compromise is size, speed, reliability, flexibility, etc. Appimage, Flatpak or Snap?
6) Linux competitors seem to not have these 3rd party compiled application problems. Windows x86, Apple & Android.
8 • 3rd party (by Tim on 2021-05-10 02:17:09 GMT from United States)
My primary method wasn’t in the poll- go seek out packages from the publisher’s website. At this point, it’s really only Chrome, Zoom, and Teams for me and 3rd party. Sometimes I’ll grab the Oracle Virtualbox packages if something is wonky about the one in the release I’m using.
I do use PPAs, though, mostly like mini backports repos. These are helpful in switching between Ubuntu and Mint. I’m currently running Ubuntu Mate 21.04, if I switch to a future Mint 20.2 (based on 20.04) that would be a downgrade of some packages and a PPA can solve that problem. The one third party project I’ve used a PPA for is Regolith, and it worked really well.
In general though, if it’s not in Debian/Mint/Ubuntu there’s usually a reason, and I don’t try and install it. If I really need it I put it in a VM. I keep one running Manjaro, and several running obsolete Ubuntus so I can use discontinued packages.
9 • Security Issue with AUR (by M.Z. on 2021-05-10 02:23:13 GMT from United States)
I think the unvetted part of the AUR Q&A is important & AURs generally aren't well vetted & have some security risk. I trust .deb & .rpm from my various distros & flatpack, but AUR seems a bit too close to websites with free windows software. There were even reports of compromised packages coming form AURs once or twice, including here on DW. Not a common problem by any means, but I use Linux in part for the security & AUR isn't good enough in my opinion.
https://distrowatch.com/dwres.php?resource=showheadline&story=6389
10 • GNU Guix preferable to Nix (by Andy Prough on 2021-05-10 02:26:30 GMT from United States)
Your survey should have listed the GNU Guix third party package manager. It's actually dedicated to all totally libre software, unlike many of the others you listed.
I tried the Nix package manager tonight after reading Jesse's writeup. At least on Devuan it was not a good experience. It installed its own version of systemd, which I did not want, and then the package I did want to use Nix to install started crashing as soon as I opened it. Needless to say, I uninstalled Nix and all its packages quickly.
I've installed the Guix package manager on numerous distros and have had good success with it. I don't think the Guix package manager would install a version of systemd like Nix did, since the Guix distro uses Shepherd init system instead of systemd.
11 • (correction) (a mea culpa moment) (by RJA on 2021-05-10 02:33:36 GMT from United States)
For post #6, I meant this:
"because one mirror randomly didn't have file X, but the next mirror I tried had file X, but it didn't have file Y"
12 • Nix Package Manager (by RJZ on 2021-05-10 04:28:44 GMT from United States)
#10 - sorry to see you had problems with Nix. I've used it with Void and MacOS with no problems. Maybe that's because they do not use systemd.
I find it amazing that I can use Nix on almost any distro and not have to switch between apt, zypper, pacman, xbps, homebrew, etc when I want to install new packages (other than system updates). More over, the nix language allows me to keep an identical environment across all those disros, by using the nix language declaratively. Nix is a little different, but it's not hard to get started.
I prefer AppImage over flatpak or PPA, when not using Nix.
13 • third party packages (by Titus_Groan on 2021-05-10 06:27:21 GMT from New Zealand)
I have required only one non-distro supported package in all my Linux years, +20 of them. my needs are simple.
Ultimaker_Cura 3d printer software, available and downloaded as an Appimage.
Unfortunately, it didnt work initially, but that turned out to be due to my system - 32bit.
booted into a 64bit system and it works as intended.
sadly, the Ultimaker_Cura website makes no mention of the 64bit requirement.
Not a big fan of "comminity repos" such as PPAs and AUR, as the trust level is difficult to attain. The risk of a "poisoned" package, either deliberately by the creator or by a external agent due to a security breach is too great for me.
14 • Poll - 3rd party software (by Hoos on 2021-05-10 07:21:38 GMT from Singapore)
I chose "other". If you run MX Linux or any other distro whose developers have a great willingness to take package requests, you can get your packages built by the distro developers themselves. Assuming you trust your distro developers, that should provide a higher level of trust than simply depending on the unknown person creating the pkgbuild script in AUR.
On the other hand, when I use Arch-based distros, I see nothing wrong with a careful and judicious use of the AUR. The pkgbuild contents can be checked,.
15 • 3rd party software - Other (by Someguy on 2021-05-10 07:36:06 GMT from United Kingdom)
'Fraid not very adventurous in this respect. For Opera browser - visit website, seems trustworthy, rather safe & reliable, etc. Since Mint dropped Brasero, been a big problem installing it on new systems - clearly not flavour of the month with any distro, but I used to like it. As for other daily ops., a surfeit of native offerings to achieve everything I need.
16 • Third-Party Sources (by eganonoa on 2021-05-10 07:47:21 GMT from Netherlands)
I've pretty much tried them all, I think: Flatpak, Snap, Appimage, Guix, AUR, OBS, Copr, PPA, etc. My impressions are:
1. Arch users have a pretty unrealistic impression of the AUR derived, I think, from this strange mystique that Arch has and for which the question posed is a great example. I think there are a lot of people using Arch that think it is some sort of magic, ultra-hacker distro that does things so much differently from everyone else, but who ultimately actually don't have a ton of experience with the wider linux world. My experience with the AUR is that it is OK, but nothing special. It's just that Arch users are often much more reliant on it because of how limited the number of packages in the official repos are. I find it on par with PPAs for Ubuntu in terms of long-term stability (and that it not a compliment) but much more necessary given the limited number of packages officially available.
2. SUSE Open Build Service has been by far the most reliable and transparent of the distro-specific ones. software.opensuse.org and its integration with YAST is just a pleasure to use. It makes the AUR look very amateurish in comparison.
3. Among the cross-distro ones, Flatpaks are pretty good. I like Snaps for the command line tools. Guix/Nix are cool, but too complicated for me. I can't really get on board with Appimages. Individual updates are a pain. And the general direction, away from some form of trustworthy package manager and towards the Windows model of software distribution, just runs against the grain one of the key features of linux distros and their security model.
4. There is no substitute for the big, trustworthy package managers. The more reliant on third-party sources you are, the worse things ultimately are. Debian, Ubuntu, Fedora/RHEL, and to a lesser extent SUSE, don't need to place so much emphasis on something like the AUR because they ship so many packages already. I prefer to use one of those, and layer on top things I can't get either through flatpak or building myself, rather than relying on unknown sources to compile things for me.
17 • Third party software (by Jymm on 2021-05-10 10:00:32 GMT from United States)
As a Ubuntu user (Mate) I use PPA'a and gdebi for .deb programs.
18 • Third party Software (by kc1di on 2021-05-10 10:21:33 GMT from United States)
I use PPA's and Appimages also direct .deb files I was surprized that appimages was not included in the survey.
19 • 3rd party soft (by Compass on 2021-05-10 10:26:56 GMT from Spain)
I prefere AppImages. I would like they were more popular, abundant and easy to find.
20 • Third party software (by slink on 2021-05-10 10:49:03 GMT from United States)
I agree with #16 above. Arch folks are practically forced to use AUR because the selection in their official repos is pretty small when compared to some other distros.
That said, I generally had good luck out of AUR back when I ran Manjaro. The main issue I've had with AUR is what eventually drove me off Arch and its derivatives. AUR is also bleeding edge and I've run into situations where packages are released onto it with bugs that make the package unfit for use.
21 • Third party software (by Kazlu on 2021-05-10 10:49:18 GMT from France)
I voted Flatpak because this would probably be my choice if all the options were available. But in reality, every project has two or three methods tops for installing outside distro repositories, so I do with what is available. That being said, my usage of third party software is extremely rare.
22 • AUR (by DachshundMan on 2021-05-10 11:39:35 GMT from United Kingdom)
When I was running Manjaro some time ago I used the AUR but it broke my system several times and on a few occasions it stopped subsequent upgrades from happening. After that I decided not to use the AUR and moved to Mint so I could get a better range of software.
I understand the imperative for developers to use Flatpak, Snap etc but I really do not like the security aspects or the extra size of downloads when using them.
23 • Tribblix worked weel for me 1st try (by Tribblexer on 2021-05-10 12:28:07 GMT from Greece)
Apart from great documentation on solaris forks and Tribblix in particular, there are a few videos showing how easy it is to install what you want with it, by 3rd parties. It is very refreshing to know that people still like systems like this, following unix tradition and precision, and not everyone has turned into a "smart-phone" dummy clicking and swiping everything to work.
There is hope after all!
24 • User repositories (by Userrepo on 2021-05-10 12:59:04 GMT from Germany)
As a software developer I use distro user repositories also to make my software more accessible to users. I publish on PyPI (the Python Package Index), Arch's AUR and Gentoo's User Repository GURU (not listed). This way I also get my software listed on https://repology.org/
Publishing on Ubuntu's PPA's would not give me much exposure to a user community: it's a personal archive, not a community archive.
25 • Poll (by dragonmouth on 2021-05-10 13:26:36 GMT from United States)
With 50k+ packages,each, available in PCLinuxOS and MX Linux default repositories, I have no need for third party software, therefore, I do not use any of the methods mentioned.
26 • Third party software (by Gentoo on 2021-05-10 14:36:50 GMT from United States)
I use Gentoo and if I need third party software I first check to see if it has a Docker container version or just compile from source myself. It's not that bad really, especially with Portage, complex dependency trees are really easy to resolve.
27 • @ Jesse JingOS (by kacz on 2021-05-10 14:40:15 GMT from Canada)
Well, you should've installed JingOS on a tablet, or at least on a touchscreen laptop to try it. It is not a desktop OS, after all.
28 • JingOS (by Jesse on 2021-05-10 14:48:55 GMT from Canada)
@27: "Well, you should've installed JingOS on a tablet, or at least on a touchscreen laptop to try it. It is not a desktop OS, after all."
If you would have read the review you would have noticed I did try to install JingOS on a laptop with a touch screen for precisely the reason you specified.
29 • AUR (by Tad Strange on 2021-05-10 15:10:37 GMT from Canada)
I've only needed the AUR to get Google Chrome and the Epson Eco-tank drivers. Anything else I've needed has been available in the repos.
I've tried a few other applications, but with limited success, especially if I've used yay rather than the pamac gui - dependencies or prerequisites don't always get satisfied with the source builds, leading to frustration.
The warnings about "unvetted" software don't phase me much, not after a few decades of running whatever free or shareware that looks interesting. I'm more concerned about it plain not running or maintenance ending, which is why I prefer the official repos.
Appimage seems interesting as well, though I've only used it for small utilities.
Running Manjaro as my primary desktop, though I've got either older machines or VMs for looking at Reborn and Endeavour to see how they compare.
30 • Jing (by Tad Strange on 2021-05-10 15:27:10 GMT from Canada)
Forgot re: JingOS (love the name). I don't see the point in the x86 version of it, but it's something I'll keep an eye on for when my cheap Teclast 'droid tablet falls hopelessly out of date once they stop patching it.
If there are any other similar tablet-centric sytems worth looking at, I'd be interested in learning more about them.
31 • Third party software (by david on 2021-05-10 15:34:48 GMT from United Kingdom)
When I used CentOS I had to enable several extra repositories, but PCLinuxOS has almost everything I want — one rpm downloaded from the developers and one from Mageia, and that's it. My 32-bit computer uses Debian, so there's no chance of running out of software there. Things like Snap and Flatpack seem to be just unnecessarily importing Windows methods to Linux.
32 • Third party software (by Robert on 2021-05-10 15:51:34 GMT from United States)
I like the aur well enough, but I don't consider it the be-all-end-all of third party software. I've mostly used it for gaming related stuff like proton and mangohud. Compiling wine and proton from source takes so long even with a decent system that you're probably better off grabbing a precompiled package from a reputable source like GloriousEggroll. Mangohud I could never get to work, but whether thats the fault of the pkgbuild or the source I couldn't say.
Flatpak is cool, and I do use it for a couple things, but it doesn't cover a lot of software. I would like to use it for firefox, but I couldn't figure out how to migrate my open tabs from a normal install to the flat pad one.
I also like the idea of the OBS, opens use package management in general is too fussy to make it a good experience.
33 • AUR (by Tribblexer on 2021-05-10 16:14:44 GMT from Greece)
There is a difference between AUR and AUR helpers. The AUR is a repository of PKGBUILD files, wich anyone can download, read, edit, and build with pacman's makepkg.
If you trust the source it is pointing to the rest is just installation configurations to match arch-linux.
Not everything is source though, quite a few large packages are binaries (browsers, kernels, etc.) and the rest is just installation configuration. The difference is that in Arch (and forks) pacman knows what 3rd party software is installed, what dependencies are being used by them, and when there is a need for upgrade or rebuild.
The negative for AUR is that nearly half the maintainers place a pkg there once and never keep up with a speedy rolling distribution to update their PKGBUILDs. So some work has to be done by the user/sys-admin.
Manjaro doesn't have an AUR, they are using Arch's repository.
34 • tribblix install issue (by jc7628@yahoo.com on 2021-05-10 16:22:38 GMT from United States)
Attemped tribblix (m25 x64bit) install from dvd (created from checked downloaded iso) in virtualbox 6.1 resulting with indicated error.
./live_install.sh -G c1t0d0 kitchen-sink
Error: Unable to find device c1t0d0
However the format command finds:
format
AVAILABLE DISK SELECTIONS
0. c1t0d0. ...
What is going on with this?
Thanks.
35 • Tribblix (by user39 on 2021-05-10 16:36:17 GMT from United Kingdom)
I'm surprised that there are no follow-up posts to the issues Jesse had with Tribblix. It's clear from posts on the openIndiana mailing list that there are many users of Tribblix, apparently with few installation problems.
36 • Tribblix (by user39 on 2021-05-10 16:39:33 GMT from United Kingdom)
...and there we are! Crossed in the post.
37 • Instructions unclear (by CS on 2021-05-10 16:52:35 GMT from United States)
Come to think of it, I barely install any 3rd party software on my Linux systems. Bazel for building tensorflow, slack and vs code are all I can think of. All of those require me to add repos to download pre-compiled packages. I honestly can't tell if that maps to any poll choice or not.
38 • The AUR actually is better (by Ista Zahn on 2021-05-10 17:48:49 GMT from United States)
There is a lot of commentary here from people who don't like and/or don't understand the AUR. As a long time distro-hopper and (more recently) Arch user, I'm here to tell you that the AUR is better than the alternatives because it is:
1) big (at 50k or so it probably has what you want),
2) transparent (you can read the source code to see what will be downloaded from where and what will be done with it, unlike PPAs),
3) unified (there is only one AUR, as opposed to the large number of PPAs with potentially conflicting packages),
4) integrated with the system package manager (unlike Nix and Guix which are totally separate from the system package manager), and
4) easy to contribute to (PKGBUILD files and just simple shell scripts)
None of the other solutions offer all these features, and that is why Arch users love the AUR!
39 • Tribblix (by user39 on 2021-05-10 17:52:17 GMT from United Kingdom)
@34: works ok here. Running on virtualbox6, installing tribblix latest version, format command shows disk c1t0d0 as per tribblix website; su into root account; change directory to /root; run live_install script as specified; voila!
40 • Tribblix (2) (by user39 on 2021-05-10 18:56:19 GMT from United Kingdom)
There seem to be some problems with the kitchen-sink overlay; I've had more luck installing the xfce overlay by itself. At least I've got to the xfce desktop.
41 • @38 The AUR actually is better (by far2fish on 2021-05-10 19:36:44 GMT from Denmark)
You wrote
"2) transparent (you can read the source code to see what will be downloaded from where and what will be done with it, unlike PPAs),"
You are of course correct, but for most people this is an impossible task. Here are some reasons:
1. Not all people are software engineers and are hence not capable of reviewing the source code.
2. You are a software engineer, but have experience in other languages or types or languages. Reviewing the source code would take a lot of time and upskilling.
3. Not all source code is written cleanly and with intent.
4. Even the must trusted software contains unintentional security flaws, and some even contains intentional security flaws that go unnoticed for years. So this could range from the recent issue of the University of Minnesota inserting "research code" in the Linux kernel to the heartbleed bug in OpenSSL or Shellshock in Bash, that was publicly visingle in source code beween 1989 and 2014 without anyone seeing the security flaw.
Assessing source code is not easy. You need a familiary with the language, you need to understand software secuirty and you probably also need to understand how you can use tools to (at a minimum) do static code analyses.
42 • 3rd party (by Vukota on 2021-05-10 21:11:50 GMT from Serbia)
I agree with @9 that AUR is a big security concern because
(1) there are many maintainers
(2) whose identity and track record can't be well checked or proven
(3) who are often not very well skilled and may even unintentionally include malicious or flawed/outdated code
(4) as @33 mentioned there is lot of abandoned/unmaintained packages without security patches and that is hard to track
(5) as @41 mentioned no sane person will review code well (or catch anything but very obvious mistakes or intentional flaws) before building/executing/installing it using AUR.
Only real advantage of the AUR was that you had even "kitchen sync" packages there and usually latest and greatest.
I on the other hand, first look for distro packages if they are good enough, then trusted PPAs from companies and individuals with a good security and maintenance track record (like Microsoft, Google, etc.) and if neither have what I am looking for and really need, then I am using Flatpaks. Security wise, this is lighting years better than using AUR and stability/upgradability is usually pain free.
43 • Reading PKGBUILDs (by Kyle on 2021-05-10 21:12:29 GMT from United States)
@41 It sounds like the "source code" @38 is referring to is the PKGBUILD file itself, which is essentially a shell script written in a very specific format. It certainly would take a bit of command-line experience to understand its contents, but that is likely more universal among Linux users than the programming languages used to write the programs themselves.
When I install an AUR package, the things I pay the most attention to in the PKGBUILD are the "source" variable and the contents of the shell functions themselves. If the source URLs point to the program's official website and the functions don't look malicious, then I trust the PKGBUILD enough to install it. The PKGBUILD author only really has control over what their own shell functions do; the rest of my trust is in the app developers and the maintainers of pacman itself. And if I don't trust them, I don't know why I'd be installing their software in the first place!
It is perfectly understandable that somebody would not want to go through that work themselves for installing software to their system. The trade-off for the flexibility in the AUR (and more generally, the Arch Build System) is that it requires a lot of user intervention. But for those of us whose use cases and patience allow us to take advantage of those resources, there are ways of ensuring that PKGBUILDs can be trusted.
Another thing that I have not yet seen mentioned here about the AUR is that users can vote for PKGBUILDs that they like, and with enough popularity, an AUR package can be promoted to the official "community" repository. I'm not sure if that feature exists in other third-party repositories, but it definitely shows that the Arch maintainers want there to be a route for packages to go from unofficial to official.
44 • Third party software. (by Tuxedoar on 2021-05-10 22:46:57 GMT from Argentina)
Hi. Since I do my best to keep my systems both clean and secure, I don't like messing with installing untrusted software on them (that is, anything not available within the official repos of my distro of choice, Debian). The method I choose, pretty much depends on what kind of third-party software is and the way in which it's offered:
- If it's source code -> most probably, I'd go for an LXC container or VM.
- If it's an binary package (i.e, .deb package) -> most probably, I'd go for an LXC container or VM.
- If it's a single executable -> most probably, I'd go for an LXC container or VM. In few cases, though, I choose to execute them with firejail, instead!.
Take care!.
Cheers.
45 • JingOS (by Copper on 2021-05-11 05:48:25 GMT from Finland)
My test with JingOS was quite short... it didn't boot on my mini-laptop. Some meaningless text characters and stop.
46 • All cached on 4GB lego brick USB (by eee shepherd on 2021-05-11 06:26:02 GMT from United Kingdom)
Every .deb I need to upgrade from LMDE 2 to Devuan 3, are on a 4GB lego brick shaped USB drive, mounted to /var/cache/apt/archives
This helps to save the planet
The lego usb has all three clutch powers. Great brick clutch power, good usb port clutch power, and amazing own lid clutch power.
Sadly, the price keeps going up from China, they are slow, but oh so desirable
47 • Software installation (by pepa65 on 2021-05-11 07:50:21 GMT from Thailand)
The topic of software installation is I think of primary importance if your needs to beyond the provided packages. Firstly their is the native package manager of the distro. I use a member of the (wider) Ubuntu family because of the big repos and the high quality of repo maintenance. In my experience, stuff doesn't break if you stay with what is in the repos on dpkg/apt based systems. Then there is the option of easily extending the distro supported repos with PPAs, that are sometimes hosted by Ubuntu, and somewhat vetted. But they can get out of date, and should match your current generation. Another good option that is increasingly common are single binaries, like produced by Go(lang), and sometimes other build systems (Rust). I dislike python and the node/javascript ecosystem for that reason, they install a crapton of stuff in places I am not quite familiar with, and it is recommended to install stuff using virtual environment. Through bad experiences I have learned to shun software written in these languages, except when they package into a single binary, like Electron apps (but they have other downsides).
The main thing is, you don't want junk all over your filesystem that is going to break your OS. Single binaries that can be put in /usr/local where they are not going to interfere (or can be removed from easily) are ideal. That is why I hugely prefer AppImages, as they are a single binary (I extract an icon to integrate them into my GUI). Everything snap(d) is forbidden and the once or twice pointless experience with flatpak makes me shun that as well. I do build and install stuff that can be put in /usr/local, even C/C++ software that doesn't need an extensive ecosystem of files to run. Otherwise, docker (for server-side stuff) or virtualbox (for GUI stuff) are options.
48 • Package Managers (by penguinx86 on 2021-05-11 08:41:04 GMT from United States)
I was a big fan of Linux Mint with synaptic and dpkg. But I recently switched to Fedora with dnf, yum and rpm. I'm not really sure why Fedora changed yum to dnf, but it seems to still work the same. My main goal for switching was to study for the LPIC-1 exam. It seems like most third party Linux software is available in dpkg and rpm packages. it's good to know both to meet the exam objectives.
49 • 3rd party packages (by topyli on 2021-05-11 10:05:54 GMT from Finland)
Using RHEL on my desktop workstation, flatpaks really save the day, given RHEL's relatively small repositories, even with EPEL and rpmfusion added.
50 • AUR (by aurel on 2021-05-11 13:10:30 GMT from Moldova)
I don't use aur almost at all.
In most cases I find apss from AUR packaged in some repo on pkgs.org.
In most cases the package can be found in chaotic repo https://aur.chaotic.cx/
chaotic packages the most popular AUR apps, so that I don't build them myself.
Besides Pamac has good integration with both flatpak & snap.
I think that snap apps are very cool indeed.
51 • source code and the average linux user (by Otis on 2021-05-11 22:07:28 GMT from United States)
@41 (etc) I often wonder if I'm sinking into a tiny minority of linux users who don't bother with source code, shell scripts, etc. Yes the terminal is used for Aritx updates and (some of) the offered packages are not allowed in the system until they're read about here or there, but why that is done is less deep than what I see communicated in here and some other linux forums; I look for announced vulnerabilities and/or incompatabilities with what's in my system.
I'm VERY glad you guys are there.. talking about all that stuff.. you're sort of a buffer between the developers of the distros and those of us who can't/won't understand all that; we wait for what looks safe and then we move on it. That is what got most of us off Windows in the first place.
52 • third party packages (by kksheth on 2021-05-12 07:58:57 GMT from India)
Due to their philosophy, fedora do not provide patent encumbered packages. Strange is they even do not provide details. even if some packages are avaialble in copr, it is very hard to find them. Rpm fusion for fedora and epel for centos are proper answer to third party packages but not officially favored by redhat. You can say they do not encourage to provide third party packages. This has now somewhat changed due to their favoritism of flatpak but it is a way like windows.
Regarding fedora, copr is not correctly mentioned. it should be rpmfusion, epel etc. In addition yum(now dnf) has repo priority plugin which ensures which third party package you gave priority so as not to break.
In addition there are third party rpm packages available from their website. For example google-chrome
53 • Which Package Manager (by RoyD on 2021-05-12 17:21:10 GMT from United Kingdom)
The article asks about which Package manager I use. The article then goes on assuming that readers mainly use Arch, or Arch-based, distros.
As I do not, and never will, install an Arch-based distro. None of this has any bearing on my Linux usage.
I am only using Ubuntu or Debian based distros. I therefore use the built-in packages supplemented by those available using Synaptic PM, *.deb files from other sources, and the cli terminal.
54 • .deb when I can pkgsrc when I can't (by DaveT on 2021-05-12 22:01:21 GMT from United Kingdom)
A couple of decades ago I decided that the debian way of doing things was best so apt-get and aptitude allow me to install most of what I need - from the devuan repositories nowadays. For going off-piste I use 3rd party .deb when I can and use pkgsrc when I can't.
Slackware was a pain and Slackbuilds never worked for me.
Not interested in any of this Flatpack nonsense.
55 • 3rd party software installation (by Trihexagonal on 2021-05-13 06:15:04 GMT from United States)
I compile all my 3rd party programs from the FreeBSD ports tree.
I build the same programs on each of my machines found over time to meet my needs for its use as a exemplary genera purpose desktop OS IMO.
FreeBSD on a Thinkpad W520 makes an awesome MP3 player, too
56 • installing stuff (by Dave on 2021-05-14 05:16:27 GMT from United States)
If it's not in the repo and the source is available, I will try to compile it myself. Sometimes this doesn't work so well, but I have a fair success rate over the years. The situations rarely present themselves; a few times per year on average. I'm usually using something Debian-based so sometimes I will try a .deb if it's available (and seems trustworthy enough) but that is seldom the case. I refuse to use AppImage, Flatpak, Snap, etc. I have tried AppImage and Flatpak in the past and was not impressed. Never tried Nix or Guix. People often brag about the AUR but I don't see the AllURe.. doesn't seem safe to me.
Number of Comments: 56
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 1048 (2023-12-04): openSUSE MicroOS, the transition from X11 to Wayland, Red Hat phasing out X11 packages, UBports making mobile development easier |
| • Issue 1047 (2023-11-27): GhostBSD 23.10.1, Why Linux uses swap when memory is free, Ubuntu Budgie may benefit from Wayland work in Xfce, early issues with FreeBSD 14.0 |
| • Issue 1046 (2023-11-20): Slackel 7.7 "Openbox", restricting CPU usage, Haiku improves font handling and software centre performance, Canonical launches MicroCloud |
| • Issue 1045 (2023-11-13): Fedora 39, how to trust software packages, ReactOS booting with UEFI, elementary OS plans to default to Wayland, Mir gaining ability to split work across video cards |
| • Issue 1044 (2023-11-06): Porteus 5.01, disabling IPv6, applications unique to a Linux distro, Linux merges bcachefs, OpenELA makes source packages available |
| • Issue 1043 (2023-10-30): Murena Two with privacy switches, where old files go when packages are updated, UBports on Volla phones, Mint testing Cinnamon on Wayland, Peppermint releases ARM build |
| • Issue 1042 (2023-10-23): Ubuntu Cinnamon compared with Linux Mint, extending battery life on Linux, Debian resumes /usr merge, Canonical publishes fixed install media |
| • Issue 1041 (2023-10-16): FydeOS 17.0, Dr.Parted 23.09, changing UIDs, Fedora partners with Slimbook, GNOME phasing out X11 sessions, Ubuntu revokes 23.10 install media |
| • Issue 1040 (2023-10-09): CROWZ 5.0, changing the location of default directories, Linux Mint updates its Edge edition, Murena crowdfunding new privacy phone, Debian publishes new install media |
| • Issue 1039 (2023-10-02): Zenwalk Current, finding the duration of media files, Peppermint OS tries out new edition, COSMIC gains new features, Canonical reports on security incident in Snap store |
| • Issue 1038 (2023-09-25): Mageia 9, trouble-shooting launchers, running desktop Linux in the cloud, New documentation for Nix, Linux phasing out ReiserFS, GNU celebrates 40 years |
| • Issue 1037 (2023-09-18): Bodhi Linux 7.0.0, finding specific distros and unified package managemnt, Zevenet replaced by two new forks, openSUSE introduces Slowroll branch, Fedora considering dropping Plasma X11 session |
| • Issue 1036 (2023-09-11): SDesk 2023.08.12, hiding command line passwords, openSUSE shares contributor survery results, Ubuntu plans seamless disk encryption, GNOME 45 to break extension compatibility |
| • Issue 1035 (2023-09-04): Debian GNU/Hurd 2023, PCLinuxOS 2023.07, do home users need a firewall, AlmaLinux introduces new repositories, Rocky Linux commits to RHEL compatibility, NetBSD machine runs unattended for nine years, Armbian runs wallpaper contest |
| • Issue 1034 (2023-08-28): Void 20230628, types of memory usage, FreeBSD receives port of Linux NVIDIA driver, Fedora plans improved theme handling for Qt applications, Canonical's plans for Ubuntu |
| • Issue 1033 (2023-08-21): MiniOS 20230606, system user accounts, how Red Hat clones are moving forward, Haiku improves WINE performance, Debian turns 30 |
| • Issue 1032 (2023-08-14): MX Linux 23, positioning new windows on the desktop, Linux Containers adopts LXD fork, Oracle, SUSE, and CIQ form OpenELA |
| • Issue 1031 (2023-08-07): Peppermint OS 2023-07-01, preventing a file from being changed, Asahi Linux partners with Fedora, Linux Mint plans new releases |
| • Issue 1030 (2023-07-31): Solus 4.4, Linux Mint 21.2, Debian introduces RISC-V support, Ubuntu patches custom kernel bugs, FreeBSD imports OpenSSL 3 |
| • Issue 1029 (2023-07-24): Running Murena on the Fairphone 4, Flatpak vs Snap sandboxing technologies, Redox OS plans to borrow Linux drivers to expand hardware support, Debian updates Bookworm media |
| • Issue 1028 (2023-07-17): KDE Connect; Oracle, SUSE, and AlmaLinux repsond to Red Hat's source code policy change, KaOS issues media fix, Slackware turns 30; security and immutable distributions |
| • Issue 1027 (2023-07-10): Crystal Linux 2023-03-16, StartOS (embassyOS 0.3.4.2), changing options on a mounted filesystem, Murena launches Fairphone 4 in North America, Fedora debates telemetry for desktop team |
| • Issue 1026 (2023-07-03): Kumander Linux 1.0, Red Hat changing its approach to sharing source code, TrueNAS offers SMB Multichannel, Zorin OS introduces upgrade utility |
| • Issue 1025 (2023-06-26): KaOS with Plasma 6, information which can leak from desktop environments, Red Hat closes door on sharing RHEL source code, SUSE introduces new security features |
| • Issue 1024 (2023-06-19): Debian 12, a safer way to use dd, Debian releases GNU/Hurd 2023, Ubuntu 22.10 nears its end of life, FreeBSD turns 30 |
| • Issue 1023 (2023-06-12): openSUSE 15.5 Leap, the differences between independent distributions, openSUSE lengthens Leap life, Murena offers new phone for North America |
| • Issue 1022 (2023-06-05): GetFreeOS 2023.05.01, Slint 15.0-3, Liya N4Si, cleaning up crowded directories, Ubuntu plans Snap-based variant, Red Hat dropping LireOffice RPM packages |
| • Issue 1021 (2023-05-29): rlxos GNU/Linux, colours in command line output, an overview of Void's unique features, how to use awk, Microsoft publishes a Linux distro |
| • Issue 1020 (2023-05-22): UBports 20.04, finding another machine's IP address, finding distros with a specific kernel, Debian prepares for Bookworm |
| • Issue 1019 (2023-05-15): Rhino Linux (Beta), checking which applications reply on a package, NethServer reborn, System76 improving application responsiveness |
| • Issue 1018 (2023-05-08): Fedora 38, finding relevant manual pages, merging audio files, Fedora plans new immutable edition, Mint works to fix Secure Boot issues |
| • Issue 1017 (2023-05-01): Xubuntu 23.04, Debian elects Project Leaders and updates media, systemd to speed up restarts, Guix System offering ground-up source builds, where package managers install files |
| • Issue 1016 (2023-04-24): Qubes OS 4.1.2, tracking bandwidth usage, Solus resuming development, FreeBSD publishes status report, KaOS offers preview of Plasma 6 |
| • Issue 1015 (2023-04-17): Manjaro Linux 22.0, Trisquel GNU/Linux 11.0, Arch Linux powering PINE64 tablets, Ubuntu offering live patching on HWE kernels, gaining compression on ex4 |
| • Issue 1014 (2023-04-10): Quick looks at carbonOS, LibreELEC, and Kodi, Mint polishes themes, Fedora rolls out more encryption plans, elementary OS improves sideloading experience |
| • Issue 1013 (2023-04-03): Alpine Linux 3.17.2, printing manual pages, Ubuntu Cinnamon becomes official flavour, Endeavour OS plans for new installer, HardenedBSD plans for outage |
| • Issue 1012 (2023-03-27): siduction 22.1.1, protecting privacy from proprietary applications, GNOME team shares new features, Canonical updates Ubuntu 20.04, politics and the Linux kernel |
| • Issue 1011 (2023-03-20): Serpent OS, Security Onion 2.3, Gentoo Live, replacing the scp utility, openSUSE sees surge in downloads, Debian runs elction with one candidate |
| • Issue 1010 (2023-03-13): blendOS 2023.01.26, keeping track of which files a package installs, improved network widget coming to elementary OS, Vanilla OS changes its base distro |
| • Issue 1009 (2023-03-06): Nemo Mobile and the PinePhone, matching the performance of one distro on another, Linux Mint adds performance boosts and security, custom Ubuntu and Debian builds through Cubic |
| • Issue 1008 (2023-02-27): elementary OS 7.0, the benefits of boot environments, Purism offers lapdock for Librem 5, Ubuntu community flavours directed to drop Flatpak support for Snap |
| • Issue 1007 (2023-02-20): helloSystem 0.8.0, underrated distributions, Solus team working to repair their website, SUSE testing Micro edition, Canonical publishes real-time edition of Ubuntu 22.04 |
| • Issue 1006 (2023-02-13): Playing music with UBports on a PinePhone, quick command line and shell scripting questions, Fedora expands third-party software support, Vanilla OS adds Nix package support |
| • Issue 1005 (2023-02-06): NuTyX 22.12.0 running CDE, user identification numbers, Pop!_OS shares COSMIC progress, Mint makes keyboard and mouse options more accessible |
| • Issue 1004 (2023-01-30): OpenMandriva ROME, checking the health of a disk, Debian adopting OpenSnitch, FreeBSD publishes status report |
| • Issue 1003 (2023-01-23): risiOS 37, mixing package types, Fedora seeks installer feedback, Sparky offers easier persistence with USB writer |
| • Issue 1002 (2023-01-16): Vanilla OS 22.10, Nobara Project 37, verifying torrent downloads, Haiku improvements, HAMMER2 being ports to NetBSD |
| • Issue 1001 (2023-01-09): Arch Linux, Ubuntu tests new system installer, porting KDE software to OpenBSD, verifying files copied properly |
| • Issue 1000 (2023-01-02): Our favourite projects of all time, Fedora trying out unified kernel images and trying to speed up shutdowns, Slackware tests new kernel, detecting what is taking up disk space |
| • Issue 999 (2022-12-19): Favourite distributions of 2022, Fedora plans Budgie spin, UBports releasing security patches for 16.04, Haiku working on new ports |
| • Issue 998 (2022-12-12): OpenBSD 7.2, Asahi Linux enages video hardware acceleration on Apple ARM computers, Manjaro drops proprietary codecs from Mesa package |
| • Issue 997 (2022-12-05): CachyOS 221023 and AgarimOS, working with filenames which contain special characters, elementary OS team fixes delta updates, new features coming to Xfce |
| • Issue 996 (2022-11-28): Void 20221001, remotely shutting down a machine, complex aliases, Fedora tests new web-based installer, Refox OS running on real hardware |
| • Issue 995 (2022-11-21): Fedora 37, swap files vs swap partitions, Unity running on Arch, UBports seeks testers, Murena adds support for more devices |
| • Issue 994 (2022-11-14): Redcore Linux 2201, changing the terminal font size, Fedora plans Phosh spin, openSUSE publishes on-line manual pages, disabling Snap auto-updates |
| • 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.
|
| Shells.com |
Your own personal Linux computer in the cloud, available on any device. Supported operating systems include Android, Debian, Fedora, KDE neon, Kubuntu, Linux Mint, Manjaro and Ubuntu, ready in minutes.
Starting at US$4.95 per month, 7-day money-back guarantee
|
| Random Distribution | 
LuninuX OS
LuninuX OS is an Ubuntu-based Linux distribution designed to be beautiful, clean, simple, fast, and stable.
Status: Dormant
|
| 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.
|
|
• 
• 
• 
• 
• 
• 
• 
