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) |
|
|
|
bc1qxes3k2wq3uqzr074tkwwjmwfe63z70gwzfu4lx lnurl1dp68gurn8ghj7ampd3kx2ar0veekzar0wd5xjtnrdakj7tnhv4kxctttdehhwm30d3h82unvwqhhxarpw3jkc7tzw4ex6cfexyfua2nr 86fA3qPTeQtNb2k1vLwEQaAp3XxkvvvXt69gSG5LGunXXikK9koPWZaRQgfFPBPWhMgXjPjccy9LA9xRFchPWQAnPvxh5Le paypal.me/distrowatchweekly • patreon.com/distrowatch |
|
Extended Lifecycle Support by TuxCare |
|
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 1095 (2024-11-04): Fedora 41 Kinoite, transferring applications between computers, openSUSE Tumbleweed receives multiple upgrades, Ubuntu testing compiler optimizations, Mint partners with Framework |
• Issue 1094 (2024-10-28): DebLight OS 1, backing up crontab, AlmaLinux introduces Litten branch, openSUSE unveils refreshed look, Ubuntu turns 20 |
• Issue 1093 (2024-10-21): Kubuntu 24.10, atomic vs immutable distributions, Debian upgrading Perl packages, UBports adding VoLTE support, Android to gain native GNU/Linux application support |
• Issue 1092 (2024-10-14): FunOS 24.04.1, a home directory inside a file, work starts of openSUSE Leap 16.0, improvements in Haiku, KDE neon upgrades its base |
• Issue 1091 (2024-10-07): Redox OS 0.9.0, Unified package management vs universal package formats, Redox begins RISC-V port, Mint polishes interface, Qubes certifies new laptop |
• Issue 1090 (2024-09-30): Rhino Linux 2024.2, commercial distros with alternative desktops, Valve seeks to improve Wayland performance, HardenedBSD parterns with Protectli, Tails merges with Tor Project, Quantum Leap partners with the FreeBSD Foundation |
• Issue 1089 (2024-09-23): Expirion 6.0, openKylin 2.0, managing configuration files, the future of Linux development, fixing bugs in Haiku, Slackware packages dracut |
• Issue 1088 (2024-09-16): PorteuX 1.6, migrating from Windows 10 to which Linux distro, making NetBSD immutable, AlmaLinux offers hardware certification, Mint updates old APT tools |
• Issue 1087 (2024-09-09): COSMIC desktop, running cron jobs at variable times, UBports highlights new apps, HardenedBSD offers work around for FreeBSD change, Debian considers how to cull old packages, systemd ported to musl |
• Issue 1086 (2024-09-02): Vanilla OS 2, command line tips for simple tasks, FreeBSD receives investment from STF, openSUSE Tumbleweed update can break network connections, Debian refreshes media |
• Issue 1085 (2024-08-26): Nobara 40, OpenMandriva 24.07 "ROME", distros which include source code, FreeBSD publishes quarterly report, Microsoft updates breaks Linux in dual-boot environments |
• Issue 1084 (2024-08-19): Liya 2.0, dual boot with encryption, Haiku introduces performance improvements, Gentoo dropping IA-64, Redcore merges major upgrade |
• Issue 1083 (2024-08-12): TrueNAS 24.04.2 "SCALE", Linux distros for smartphones, Redox OS introduces web server, PipeWire exposes battery drain on Linux, Canonical updates kernel version policy |
• Issue 1082 (2024-08-05): Linux Mint 22, taking snapshots of UFS on FreeBSD, openSUSE updates Tumbleweed and Aeon, Debian creates Tiny QA Tasks, Manjaro testing immutable images |
• Issue 1081 (2024-07-29): SysLinuxOS 12.4, OpenBSD gain hardware acceleration, Slackware changes kernel naming, Mint publishes upgrade instructions |
• Issue 1080 (2024-07-22): Running GNU/Linux on Android with Andronix, protecting network services, Solus dropping AppArmor and Snap, openSUSE Aeon Desktop gaining full disk encryption, SUSE asks openSUSE to change its branding |
• Issue 1079 (2024-07-15): Ubuntu Core 24, hiding files on Linux, Fedora dropping X11 packages on Workstation, Red Hat phasing out GRUB, new OpenSSH vulnerability, FreeBSD speeds up release cycle, UBports testing new first-run wizard |
• Issue 1078 (2024-07-08): Changing init software, server machines running desktop environments, OpenSSH vulnerability patched, Peppermint launches new edition, HardenedBSD updates ports |
• Issue 1077 (2024-07-01): The Unity and Lomiri interfaces, different distros for different tasks, Ubuntu plans to run Wayland on NVIDIA cards, openSUSE updates Leap Micro, Debian releases refreshed media, UBports gaining contact synchronisation, FreeDOS celebrates its 30th anniversary |
• Issue 1076 (2024-06-24): openSUSE 15.6, what makes Linux unique, SUSE Liberty Linux to support CentOS Linux 7, SLE receives 19 years of support, openSUSE testing Leap Micro edition |
• Issue 1075 (2024-06-17): Redox OS, X11 and Wayland on the BSDs, AlmaLinux releases Pi build, Canonical announces RISC-V laptop with Ubuntu, key changes in systemd |
• Issue 1074 (2024-06-10): Endless OS 6.0.0, distros with init diversity, Mint to filter unverified Flatpaks, Debian adds systemd-boot options, Redox adopts COSMIC desktop, OpenSSH gains new security features |
• Issue 1073 (2024-06-03): LXQt 2.0.0, an overview of Linux desktop environments, Canonical partners with Milk-V, openSUSE introduces new features in Aeon Desktop, Fedora mirrors see rise in traffic, Wayland adds OpenBSD support |
• Issue 1072 (2024-05-27): Manjaro 24.0, comparing init software, OpenBSD ports Plasma 6, Arch community debates mirror requirements, ThinOS to upgrade its FreeBSD core |
• Issue 1071 (2024-05-20): Archcraft 2024.04.06, common command line mistakes, ReactOS imports WINE improvements, Haiku makes adjusting themes easier, NetBSD takes a stand against code generated by chatbots |
• Issue 1070 (2024-05-13): Damn Small Linux 2024, hiding kernel messages during boot, Red Hat offers AI edition, new web browser for UBports, Fedora Asahi Remix 40 released, Qubes extends support for version 4.1 |
• Issue 1069 (2024-05-06): Ubuntu 24.04, installing packages in alternative locations, systemd creates sudo alternative, Mint encourages XApps collaboration, FreeBSD publishes quarterly update |
• Issue 1068 (2024-04-29): Fedora 40, transforming one distro into another, Debian elects new Project Leader, Red Hat extends support cycle, Emmabuntus adds accessibility features, Canonical's new security features |
• Issue 1067 (2024-04-22): LocalSend for transferring files, detecting supported CPU architecure levels, new visual design for APT, Fedora and openSUSE working on reproducible builds, LXQt released, AlmaLinux re-adds hardware support |
• Issue 1066 (2024-04-15): Fun projects to do with the Raspberry Pi and PinePhone, installing new software on fixed-release distributions, improving GNOME Terminal performance, Mint testing new repository mirrors, Gentoo becomes a Software In the Public Interest project |
• Issue 1065 (2024-04-08): Dr.Parted Live 24.03, answering questions about the xz exploit, Linux Mint to ship HWE kernel, AlmaLinux patches flaw ahead of upstream Red Hat, Calculate changes release model |
• Issue 1064 (2024-04-01): NixOS 23.11, the status of Hurd, liblzma compromised upstream, FreeBSD Foundation focuses on improving wireless networking, Ubuntu Pro offers 12 years of support |
• Issue 1063 (2024-03-25): Redcore Linux 2401, how slowly can a rolling release update, Debian starts new Project Leader election, Red Hat creating new NVIDIA driver, Snap store hit with more malware |
• Issue 1062 (2024-03-18): KDE neon 20240304, changing file permissions, Canonical turns 20, Pop!_OS creates new software centre, openSUSE packages Plasma 6 |
• Issue 1061 (2024-03-11): Using a PinePhone as a workstation, restarting background services on a schedule, NixBSD ports Nix to FreeBSD, Fedora packaging COSMIC, postmarketOS to adopt systemd, Linux Mint replacing HexChat |
• Issue 1060 (2024-03-04): AV Linux MX-23.1, bootstrapping a network connection, key OpenBSD features, Qubes certifies new hardware, LXQt and Plasma migrate to Qt 6 |
• Issue 1059 (2024-02-26): Warp Terminal, navigating manual pages, malware found in the Snap store, Red Hat considering CPU requirement update, UBports organizes ongoing work |
• Issue 1058 (2024-02-19): Drauger OS 7.6, how much disk space to allocate, System76 prepares to launch COSMIC desktop, UBports changes its version scheme, TrueNAS to offer faster deduplication |
• Issue 1057 (2024-02-12): Adelie Linux 1.0 Beta, rolling release vs fixed for a smoother experience, Debian working on 2038 bug, elementary OS to split applications from base system updates, Fedora announces Atomic Desktops |
• Issue 1056 (2024-02-05): wattOS R13, the various write speeds of ISO writing tools, DSL returns, Mint faces Wayland challenges, HardenedBSD blocks foreign USB devices, Gentoo publishes new repository, Linux distros patch glibc flaw |
• Issue 1055 (2024-01-29): CNIX OS 231204, distributions patching packages the most, Gentoo team presents ongoing work, UBports introduces connectivity and battery improvements, interview with Haiku developer |
• Issue 1054 (2024-01-22): Solus 4.5, comparing dd and cp when writing ISO files, openSUSE plans new major Leap version, XeroLinux shutting down, HardenedBSD changes its build schedule |
• Issue 1053 (2024-01-15): Linux AI voice assistants, some distributions running hotter than others, UBports talks about coming changes, Qubes certifies StarBook laptops, Asahi Linux improves energy savings |
• Issue 1052 (2024-01-08): OpenMandriva Lx 5.0, keeping shell commands running when theterminal closes, Mint upgrades Edge kernel, Vanilla OS plans big changes, Canonical working to make Snap more cross-platform |
• Issue 1051 (2024-01-01): Favourite distros of 2023, reloading shell settings, Asahi Linux releases Fedora remix, Gentoo offers binary packages, openSUSE provides full disk encryption |
• Issue 1050 (2023-12-18): rlxos 2023.11, renaming files and opening terminal windows in specific directories, TrueNAS publishes ZFS fixes, Debian publishes delayed install media, Haiku polishes desktop experience |
• Issue 1049 (2023-12-11): Lernstick 12, alternatives to WINE, openSUSE updates its branding, Mint unveils new features, Lubuntu team plans for 24.04 |
• 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 |
• Full list of all issues |
Star Labs |
Star Labs - Laptops built for Linux.
View our range including the highly anticipated StarFighter. Available with coreboot open-source firmware and a choice of Ubuntu, elementary, Manjaro and more. Visit Star Labs for information, to buy and get support.
|
Random Distribution |
LliureX
LliureX is a project of the Council of Culture, Education and Sport at the Municipality of Valencia, Spain. The LliureX distribution is an Edubuntu-based live and installation DVD with support for the Valencian and Spanish languages. It is intended as an operating system for educational institutions in the Valencia region. LliureX uses exclusively free software and is distributed free of charge.
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.
|
|