DistroWatch Weekly |
DistroWatch Weekly, Issue 916, 10 May 2021 |
Welcome to this year's 18th issue of DistroWatch Weekly!
Whichever operating system a person runs, a key feature is how to get applications to run on the platform. While most Linux distributions offer a curated collection of software through official repositories, people often want to access additional software. There are many approaches to acquiring extra software, varying from collections of ports to portable package formats and community repositories. We talk about some of these options in our Questions and Answers column. What is your primary method of acquiring third-party software? Let us know in this week's Opinion Poll. First though we take a look at a Linux distribution called JingOS designed with touch interfaces, specifically tablet computers, in mind. We also talk about a project in the illumos family called Tribblix which takes on a retro style. Plus we report on Fedora's new i3 window manager spin and pfSense providing an experimental WireGuard package. We also report on work being done, particularly with wireless support, in the FreeBSD project. Plus we are pleased to share the releases of the past week and list the torrents we are seeding. We wish you all a fantastic week and happy reading!
Content:
- Review: JingOS 0.8 and Tribblix
- News: Fedora introduces i3 spin, pfSense provides WireGuard packages, FreeBSD improves wireless support
- Questions and answers: Installing third-party software on distributions
- Released last week: GParted Live 1.3.0-1
- Torrent corner: Bluestar, GParted Live, IPFire, KDE neon, Mabox, Manjaro, Plamo, SalientOS, SparkyLinux, SystemRescue
- Opinion poll: Methods for installing third party software
- New distributions: VzLinux
- Reader comments
|
Feature Story (by Jesse Smith) |
JingOS 0.8
One of the most recent additions to the DistroWatch database is JingOS, an Ubuntu-based Linux distribution for tablet computers. The project aims to run both GNU/Linux and Android applications via a graphical user interface which is designed to work in a familiar way on touch screens. While early versions of JingOS were developed for ARM-based devices, JingOS 0.8 is the project's first version to run on x86 processors.
The JingOS project requires that people register their e-mail address to obtain the project's free download. A download link is then sent to our e-mail address. When I downloaded an earlier version of JingOS (version 0.6) the download link was for the distribution's ISO file directly. When I downloaded version 0.8 I was given a link to the project's torrent file. At first my torrent download only had two seeders with an average download speed of 20kB/s. This eventually rose to eight seeders at 400kB/s, which is unusually slow compared to most free mirrors available these days. The ISO file's total size is 2.4GB so the download took over two hours.
Booting from the distribution's install media causes the system to start with a self-check of the media. This check can be skipped by pressing Ctrl+C. The screen then goes entirely black for a while. After a few minutes I started testing keyboard input without any response. The only thing I could do was to switch between terminals using the Ctrl+Alt+Function keys.
I found the first terminal remained blank, the second terminal showed a colourful background and a clock displaying UTC time. Terminals three through six all displayed a console login prompt. The login prompts identify the distribution as KDE neon's Unstable Edition.
There are no controls we can interact with on the graphical terminals and no obvious username/password combination worked on the text consoles. I checked the JingOS documentation and found no login information. The website's only instructions for working with the live media are as follows:
Install guide(English): Boot from USB or CD, click Install System.
This is not helpful as there are no buttons or windows in any of the available terminals or screens. I tried booting JingOS a few times and never found a way to get it to proceed any further than these bare screens.
* * * * *
Tribblix
The next project I decided to take a look at this week was Tribblix. The Tribblix project offers an "operating system distribution derived from OpenSolaris, OpenIndiana, and illumos, with a retro style and modern components. The base kernel and commands are from illumos, with a few components currently repackaged from OpenIndiana (mostly X11, some other oddments); pretty much everything else has been rebuilt from scratch. It is very much a traditional system. Software is distributed as SVR4 packages, lightweight window managers are preferred over heavy desktop environments, the primary desktop option is Xfce, and MATE and Enlightenment are also available, plus many others. The system is flexible, fast, and familiar to those who've used Solaris in the past, while shipping modern software on the solid foundation it's based on.
Tribblix isn't just a spin or repackaging of another illumos distribution. It's a completely independent distribution that, while sharing the key illumos technologies such as ZFS, zones, DTrace, and SMF, has been essentially built from scratch, with its own build and packaging system."
(Thank you to the developers for this rather detailed and technical description. It's a rare treat to know exactly what a project is and what it is meant to do.)
Tribblix is currently available for 64-bit (x86_64) processors and there is an older, legacy build for 32-bit (x86) machines. The project currently supplies a build for SPARC machines too. The operating system comes in two main editions: Standard (999MB) and Minimal (238MB). I decided to try the Standard edition, which is tagged as version 0m24.1.
Booting from the Tribblix media brings up a text console that displays green font on a black background. Apparently we are going really retro with this distribution. We are asked to pick our language from a numbered list and then shown a text console with a login prompt.
Installing
The Tribblix website provides the default login credentials (the username and password are both "jack"). The website's documentation also tells us we can run a script called live_install.sh to install the operating system to our hard drive. The script just needs to be given the device name of our hard drive.
A wall of text scrolls by as the operating system is installed. When it is finished we are returned to the command prompt. According to the website's documentation we can run the install script again and pass it the names of package bundles to add extra software such as desktop environments and development tools. There is a meta package called kitchen-sink which installs both desktop and development utilities and is the recommended approach to setting up a multi-purpose system.
I tried to install the kitchen-sink package and this appeared to work at first, but ended up displaying thousands of "cannot open file" errors on the terminal. This was followed by new packages being downloaded and then another series of errors indicating there was no space left on the storage device. This seemed odd at first because only about 10% of my on-disk filesystem was consumed. However, in hindsight, I suspect the download process was trying to save new packages either in RAM or to my live media, rather than the hard drive. I resolved to try installing packages again later, once I had booted into my new copy of Tribblix.
First impressions and package management
My fresh copy of Tribblix booted to a console and displayed a login prompt. The "jack" username and password still worked on the locally installed copy of Tribblix. I tried to use the startx and startxfce4 commands mentioned in the documentation and discovered neither command was found. This confirmed that the errors displayed during the initial setup had been accurate and no package bundles (Tribblix calls them "overlays") had been set up successfully.
The Tribblix website mentions a tool called zap which handles fetching new overlays once the operating system has been installed. We can use zap to list installed overlays, see which ones are available, and fetch new ones. The zap command works a lot like APT or DNF in the Linux world, but with a slightly modified syntax.
Graphical desktops
I again opted to try to install the kitchen-sink overlay and this appeared to be successful. I did end up with some development tools install and I could run startx to get a minimal window manager, powered by TWM. Unfortunately TWM doesn't provide us with much apart from opening a few virtual terminals and displaying a clock. It's a very minimal interface and one which did not respond to mouse input.
I decided to close TWM and switch to the Xfce desktop environment. The Xfce environment started to load and then crashed. This happened each time I tried to start Xfce, whether it was set to be my default graphical interface or not. Since TWM had worked, at least partially, I then tried to install the Openbox window manager to see if it would get me further along. Openbox failed to install, but the MATE desktop did install through zap. However, the MATE session also crashed prior to successfully getting to the desktop screen.
This left me, effectively, without a desktop environment. Running TWM worked, but wasn't much help as far as dealing with graphical workloads and so I played around with Tribblix as a console-only system. I found the operating system consumed about 250MB of RAM when logged into the console. A chunk of this memory appears to be used as cache for ZFS which is the default filesystem. The ZFS tools are installed and worked successfully for me.
Other observations
Some software on the operating system is showing its age. For instance, the GNU Compiler Collection is available, but is stuck on version 7.3 while modern Linux distributions ship version 10 and even Debian's aging Stable branch uses version 8.3. It seems Tribblix suffers from the same issue OpenIndiana has of often trailing behind in software versions.
Tribblix ships with standard UNIX command line tools and manual pages. However, some components seem to be missing. For instance, whenever I ran the shutdown command to halt or reboot the system, an error would be displayed saying the wall command could not be found. This is the program which would normally inform other users on the system that Tribblix was being shutdown.
Originally I had started testing Tribblix in a VirtualBox instance. I did switch gears and try the operating system on my laptop too for a while. However, Tribblix was unable to detect my laptop's wireless card which meant it was limited to working as a standalone machine during that portion of my trial and unable to install new software.
Conclusions
I did not have a great time with Tribblix. The concept of the illumos platform with a classic style appealed to me as I was a fan of Solaris in the early days of my career. On paper this operating system does offer some attractive features. I like that it provides ZFS out of the box and a fairly minimal default platform. The zap overlay manager does a nice job of fetching and setting up software on the system, at least most of the time.
However, Tribblix did not do well with regards to supporting my laptop's hardware, with getting a desktop environment up and running, or with providing even semi-recent versions of open source applications. Like its siblings in the illumos family, Tribblix feels like it is slipping behind the times and struggling to provide a polished user experience.
There are some positive aspects here and if I were setting up a server operating system or NAS that was expected to run without a desktop then I could certainly see the appeal of Tribblix, especially for people who are fans of the Solaris family of operating systems. However, there are still a number of rough edges to deal with before I think Tribblix will be in a position to replace FreeBSD or one of the mainstream Linux distributions in common roles.
* * * * *
Hardware used in this review
My physical test equipment for this review was a de-branded HP laptop with the following
specifications:
- Processor: Intel i3 2.5GHz CPU
- Display: Intel integrated video
- Storage: Western Digital 700GB hard drive
- Memory: 6GB of RAM
- Wired network device: Realtek RTL8101E/RTL8102E PCI Express Fast
- Wireless network device: Realtek RTL8188EE Wireless network card
* * * * *
Visitor supplied rating
JingOS has a visitor supplied average rating of: 5.1/10 from 11 review(s).
Have you used JingOS? You can leave your own review of the project on our ratings page.
|
Miscellaneous News (by Jesse Smith) |
Fedora introduces i3 spin, pfSense provides WireGuard packages, FreeBSD improves wireless support
One of the new features available to Fedora 34 users which largely when unnoticed in the project's latest release was the addition of the i3 spin. The new spin features the i3 window manager. Fedora Magazine highlights some of the key features of this new Fedora spin: "Fedora 34 features the brand new i3 Spin created by the Fedora i3 S.I.G. This new spin features the popular i3wm tiling window manager. This will appeal to both novices and advanced users who prefer not to use a mouse, touchpad, or other pointing device to interact with their environment. The Fedora i3 spin offers a complete experience with a minimalistic user interface and a lightweight environment. It is intended for the power user, as well as others."
* * * * *
At the start of 2021 we reported on pfSense gaining WireGuard support through new code being implemented in FreeBSD. Unfortunately a number of problems were found in the original WireGuard for FreeBSD code and it was removed and re-implemented. This resulted in FreeBSD and pfSense temporarily losing WireGuard support. Work continues to bring the lightweight VPN technology to the FreeBSD family of operating systems and pfSense is now providing a experimental package which restore WireGuard functionality. "We are pleased to be collaborating with Chris McDonald to bring WireGuard back to pfSense Plus and pfSense CE software in an experimental form. Chris approached our engineering team a few weeks ago to look for ways to collaborate on WireGuard, and we are pleased to work with him and share his results. Starting May 5, 2021, Netgate will build and distribute this new code as part of the library of extensions that exist for both development and future versions of pfSense Plus and pfSense CE."
* * * * *
The FreeBSD project has published its Quarterly Status Update for the first three months of 2021. The report talks about work being done in all aspects of the FreeBSD project along with its third-party ports. Among the infrastructure and security improvements there is some good news for people who use wireless networking: "The Intel Wireless driver update project aims to bring support for newer chipsets. During the first quarter the driver and firmware were synched from upstream so that we will have support for all modern cards currently supported in Linux. Some iwlwifi driver changes were also submitted back upstream. Several conflicts with the original implementation of LinuxKPI were or are being resolved and more LinuxKPI code was upstreamed to FreeBSD HEAD. LinuxKPI 802.11 compat code was improved and as of the day of writing we have data packets going over 11a." Further details can be found in the report.
* * * * *
These and other news stories can be found on our Headlines page.
|
Questions and Answers (by Jesse Smith) |
Installing third-party software on distributions
An-AUR-fan asks: Whenever I ask people why they use Arch Linux they almost always mention the AUR. If it's so popular then why don't other distributions have the same thing? I don't mean why can't other distributions use the AUR itself, but it must be possible to have an equivalent user-generated repository?
DistroWatch answers: The Arch User Repository, for those unfamiliar with it, is a collection of software in the form of build scripts. These build instructions are provided by the community, which is to say it's an unvetted repository supplied by third-parties. The Arch Linux wiki describes the function of the AUR as follows:
The Arch User Repository (AUR) is a community-driven repository for Arch users. It contains package descriptions (PKGBUILDs) that allow you to compile a package from source with makepkg and then install it via pacman.
The AUR provides Arch Linux users with a wide range of software which can be compiled from source code and then installed using Arch's package manager. For people who want access to a large collection of software this is quite useful.
Which brings us back to the question of why, if the AUR is so popular and useful, are there not similar community repositories available for other Linux distributions? The answer is that most of the big Linux distributions do have some method (or multiple methods) for acquiring third-party (sometimes unvetted) software. Some of these third-party repositories are cross-platform, meaning they run on almost all distributions, while others are specific to one family of distributions.
To offer a few examples of distro-specific, third-party repositories, the Fedora Project has Copr, the Ubuntu family has Personal Package Archives (also known as PPAs), the openSUSE community has a variety of third-party repositories, and Slackware Linux has SlackBuilds. The various BSDs have port collections which are usually semi-open to outside contributors.
There are other repositories which are more portable and work across most distributions. For example, most Linux distributions which feature the systemd software can run Snap packages. Almost all desktop distributions can run portable desktop applications in the form of Flatpak bundles and these bundles can usually be found in the Flathub repository. The Nix package manager can be installed on most Linux distributions and provides access to over 60,000 Nixpkgs. There are also operating system agnostic port collections such as pkgsrc.
In short, most distributions have access to multiple third-party repositories, each with their own focus or flavour. Some are portable, some are targeting specific platforms, some are for software available under more restrictive license terms. The bottom line though is most distributions have lots of ways of accessing large collections of third-party packages. They may work slightly differently than the AUR, but the general concept is the same.
* * * * *
Additional answers can be found in our Questions and Answers archive.
|
Released Last Week |
GParted Live 1.3.0-1
GParted Live is a business card-size live CD distribution with a single purpose - to provide tools for partitioning hard disks in an intuitive, graphical environment. The project's latest release, GParted Live 1.3.0-1, improves exFAT filesystem support, makes it possible to resize LUKS2 encrypted volumes, and fixes a number of potential crashes. "This release of GParted includes enhancements, bug fixes and language translation updates. Key changes include: Support resizing open LUKS2 encryption mappings; improve exFAT support such as read FS usage and set UUID; fix crash in Create New Partition dialog when changing type; avoid GParted hanging when non-named device is hung. Bug Fixes: Stop GParted hanging when non-named device is hung; avoid detecting exfat-utils commands as exfatprogs commands; Add support for reading exFAT usage and updating the UUID; fix minor typos in docs (!68) and comments; add Ukrainian translation of docs; fix test suite failing in test_PipeCapture." Additional information can be found in the project's release announcement and in the release notes.
* * * * *
Development, unannounced and minor bug-fix releases
|
Torrent Corner |
Weekly Torrents
The table below provides a list of torrents DistroWatch is currently seeding. If you do not have a bittorrent client capable of handling the linked files, we suggest installing either the Transmission or KTorrent bittorrent clients.
Archives of our previously seeded torrents may be found in our Torrent Archive. We also maintain a Torrents RSS feed for people who wish to have open source torrents delivered to them. To share your own open source torrents of Linux and BSD projects, please visit our Upload Torrents page.
Torrent Corner statistics:
- Total torrents seeded: 2,434
- Total data uploaded: 37.5TB
|
Upcoming Releases and Announcements |
Summary of expected upcoming releases
|
Opinion Poll (by Jesse Smith) |
Methods for installing third party software
In this week's Questions and Answers column we talked about methods for installing third-party software packages - those not available in a distribution's official repositories. What is your primary method for installing third-party packages on your distribution?
You can see the results of our previous poll on the Arch Linux system installer in last week's edition. All previous poll results can be found in our poll archives.
|
Primary method for installing third-party software
AppImage: | 178 (11%) |
AUR: | 343 (21%) |
Copr/Contrib/PPA repo: | 234 (14%) |
Flatpak: | 229 (14%) |
Nix: | 10 (1%) |
pkgsrc: | 18 (1%) |
Ports/Slackbuilds: | 61 (4%) |
Snap: | 79 (5%) |
Source code: | 151 (9%) |
Other: | 172 (10%) |
I do not install third-party software: | 170 (10%) |
|
|
Website News |
New distributions added to waiting list
- VzLinux. VzLinux has been a base operating system for OpenVz and Virtuozzo Hybrid Server. Additionally, it is used as a guest operating system for containers and virtual machines. The distribution is 1:1 compatible with Red Hat Enterprise Linux.
* * * * *
DistroWatch database summary
* * * * *
This concludes this week's issue of DistroWatch Weekly. The next instalment will be published on Monday, 17 May 2021. Past articles and reviews can be found through our Article Search page. To contact the authors please send e-mail to:
- Jesse Smith (feedback, questions and suggestions: distribution reviews/submissions, questions and answers, tips and tricks)
- Ladislav Bodnar (feedback, questions, donations, comments)
- Bruce Patterson (podcast)
|
|
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 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 |
• Issue 993 (2022-11-07): Static Linux, working with just a kernel, Mint streamlines Flatpak management, updates coming to elementary OS |
• Full list of all issues |
Star Labs |

Star Labs - Laptops built for Linux.
View our range including the highly anticipated StarFighter. Available with coreboot open-source firmware and a choice of Ubuntu, elementary, Manjaro and more. Visit Star Labs for information, to buy and get support.
|
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 | 
wattOS
wattOS is a fast desktop Linux distribution based on Debian. Using the lightweight Openbox window manager as its default user interface, the distribution strives to be as energy-efficient as possible so that it can be used on low-specification and recycled computers.
Status: Active
|
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.
|
|