 DistroWatch Weekly |
| DistroWatch Weekly, Issue 938, 11 October 2021 |
Welcome to this year's 40th issue of DistroWatch Weekly!
Sometimes people come along and share ideas which seem completely strange. Maybe they want to decorate their home with pennies or construct a boat entirely from toothpicks. This week we begin with a look at the unusual Pyabr project. Pyabr seeks to build an operating system, including a desktop environment, almost entirely from Python code. Read on to learn how this curious experiment is progressing. In our News section we share efforts to make an alternative to the Snap portable package client which can pull in packages from third-party repositories. What do you think of a version of Snap that is not tied to Canonical? Let us know in this week's Opinion Poll. We also share a workaround from Redcore for a recent issue that corrupts the Portage software manager while Debian publishes updated install media. Plus we share new improvements coming to the elementary OS distribution, particularly the project's software centre. In our Questions and Answers column we explore whether compiling your own kernel from source carries any benefit or performance improvements. Do you compile your own kernel builds in order to gain improved performance or hardware support? Let us know about your customizations in the comments section. Plus we are pleased to share this week's releases and list the torrents we are seeding. We wish you all a fantastic week and happy reading!
Content:
- Review: Pyabr OS
- News: Alternative Snap implementation, Redcore provides a solution for Portage issue, elementary OS outlines software centre improvements, Debian publishes install media updates
- Questions and answers: Benefits to building your own kernel
- Released last week: IPFire 2.27 Core 160, Feren OS 2021.10
- Torrent corner: EasyOS, ExTiX, Feren OS, IPFire, KDE neon, Manjaro, PureOS, Snal, Tails
- Upcoming releases: Ubuntu 21.10
- Opinion poll: Would you use Snap if it connected to a community repository?
- Site news: Refreshing package download links
- Reader comments
Listen to the Podcast edition of this week's DistroWatch Weekly in OGG (18MB) and MP3 (14MB) formats.
|
| Feature Story (by Jesse Smith) |
Pyabr OS
Pyabr OS was one of the latest distributions to be added to the DistroWatch waiting list. The project refers to itself as a "Python Cloud Operating System", a Linux distribution mostly written in Python. The project, which declares it is developed in Iran with multilingual support, runs on x86_64 computers and 64-bit Raspberry Pi machines.
The project's website mentions that Pyabr is a platform written in Python which offers a desktop and applications which can be run on any Linux distribution while Pyabr OS is a Debian-based operating system that runs the Pyabr software. The operating system can reportedly be installed locally or run from live media like a thumb drive. The desktop environment resembles KDE Plasma but is a custom environment called Baran which the project says is written in Python using the Qt framework.
I was unsure going into this trial how all of this related to cloud computing or services. The term "cloud" gets thrown around on the project's website, but without a clear indication of how this affects the end user. I decided to give the project a test drive and see if I could find out.
The Pyabr OS ISO file is a small download of just 447MB. The live system always stalled early in the boot process for 90 seconds while waiting for systemd to sort out its infamous "A start job is running..." warning. After that, the distribution booted quickly and displayed the Baran desktop which does look a lot like KDE Plasma at first glance due to its shared Qt framework and theme.
Early impressions
The desktop environment uses a two-panel layout. A thin panel is placed at the top of the screen. It contains an application menu and a system menu to the left and a system tray to the right. The bottom panel is thicker and also includes an application menu to the left. Icons for launching applications are arrayed along the bottom panel.
One of the first things I noticed about Pyabr is that it consumes all available CPU, even when sitting idle at the desktop. I intended to find out why and so opened a terminal and tried to run commands like top, ps, and free which I hoped would shine light on what was running in the background. None of these commands exist on Pyabr OS. The man command and many other common command line programs are also missing. The ls command works, but does not recognize any command line flags ("ls" works, but "ls -l" does not). In other words there are virtually no useful Unix-like command line programs available to help do work or troubleshoot issues.
Pyabr OS -- Trying to run common command line programs
(full image size: 109kB, resolution: 1320x691 pixels)
Next I opened the distribution's process monitor. This tool lists desktop applications which are currently open and which have been opened in the past. I'm not sure if this indicates process information is not cleared periodically or if closed application windows are not truly terminated when they disappear. No CPU or memory usage is displayed in the process monitor, making it difficult to determine what was consuming all available CPU resources.
Installing
When the live desktop session first loads, a welcome window appears. This window offers to start the install process. The installer is graphical and started off well enough with clear invitations to make up a username and password. We are asked to pick our preferred language with options being English or (I believe) Farsi. We are given the chance to toggle a guest account on/off. The installer asked if we'd like to provide a name, e-mail address, and phone number. This last step is unusual and the reason for asking for this information is not given.
Pyabr OS -- Being greeted by the system installer
(full image size: 172kB, resolution: 1320x691 pixels)
The installer has a few inconvenient quirks. For example, pressing the Tab key usually moves focus back to the previous field on a screen rather than the next. Other times it seems to select a random location. This makes navigating the interface more awkward. A bigger issue is that when the installer closes, it immediately shuts down the operating system. This means if we close the window or click the Cancel button at any point, the system powers off. To make matters worse, completing all the install steps causes the installer to immediately terminate which, in turn, shuts off the computer. I ran through the installer's steps four times and, each time, upon reaching the final screen the installer shut down and took the rest of the system down with it.
In short, I was only able to use Pyabr OS when it was running from live media and the system installer window always had to be open in the background or the system would immediately power off.
Included applications
Pyabr OS ships with a small collection of applications, though most of them appear to be custom, trimmed down versions of popular programs. We are given tools like a calculator, calendar, and file browser, but the tools are quite simple. The file browser just lists present folders and files and seems to be view-only in its capabilities. The calendar likewise shows dates, but doesn't seem to be able to set appointments or sync with on-line services. There is a custom web browser that does a few things differently. The main buttons and address bar are placed at the bottom of the browser window. Entering an address in the bar, such as linux.com or distrowatch.com, triggers a search and shows us web search results rather than the site we asked for. This makes it impossible to directly visit a specific URL by typing or pasting an address into the browser.
Pyabr OS -- The settings panel
(full image size: 111kB, resolution: 1320x691 pixels)
The distribution has a settings panel which presents us with a handful of custom configuration modules. There tools to help us manage user accounts, connect to local wireless networks, change the system's screen resolution, and adjust the theme of the desktop. Adjusting either the desktop resolution or theme requires restarting the system for the changes to take effect.
Software management
There is a package manager included with Pyabr. This program shows all installed desktop applications in one tab and a list of available programs in a second tab. There are just two applications in the list of available applications: Bale and Shad. Both of these programs are described simply as being messaging applications. There doesn't appear to be any way to get software updates for the base system or desktop applications.
Pyabr OS -- The software manager
(full image size: 122kB, resolution: 1320x691 pixels)
Hardware
When I started my trial I was running Pyabr OS in a VirtualBox machine. The system, despite consuming all available CPU resources, was snappy and pleasantly quick to respond. New programs opened quickly enough I suspect the entire Pyabr software suite runs from RAM. The desktop was able to automatically resize to match the VirtualBox window, which was appreciated.
I was unable to check how much memory the distribution was using or what its underlying core software was, given the limited tools provided. However, having seen the systemd warning message at each boot and knowing the distribution is based on Debian 10, I think it's a fair guess to say systemd init and Linux 4.19 are probably being used.
Later in the week I tried to run Pyabr OS on my laptop, but was unable to get the operating system to boot in either Legacy BIOS or UEFI modes. This limited my trial to running Pyabr OS in a virtual machine.
Conclusions
When I first began exploring Pyabr OS the project made me think of snakeware, but with a stronger focus on desktop and web applications. Both projects rely heavily on Python to replace the userland programs and seem to seek to remake existing popular programs with Python code.
Replacing popular programs and desktop environments with Python is certainly an interesting concept and one which I'm sure presents some interesting challenges. It may even offer us some interesting solutions too, in the long run.
The trouble though with crafting an operating system where all the popular applications, command line programs, and desktop elements are replaced by new, experimental ones is that almost all the expected functionality is missing. Most modern Linux distributions have solved (or mostly solved) many of the complex problems of computing - booting on a range of hardware, installing the operating system, packaging a web browser, providing useful command line tools, shipping full featured desktop environments, office suites, and web browsers. Projects like Pyabr OS are throwing away all of those working tools, familiarity, and a supported ecosystem of software for alternatives that often don't work, or don't work well.
They have an installer that not only doesn't work, but cannot be closed, most command line tools are missing, hardware support is lacking, the system crashed about 10% of the time while I was exploring settings or the package manager. Many of the included tools certainly worked (and my hat is off to the people who built them), but the tools usually didn't offer the same functionality as corresponding utilities included with other desktop environments.
In short, Pyabr OS is an interesting concept - a desktop operating system running almost exclusively Python code, but I'm not sure it has any useful purpose. It doesn't do anything out of the grasp of other Linux distributions and frequently lacks functionality and stability offered by other Debian-based projects.
* * * * *
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
|
| Miscellaneous News (by Jesse Smith) |
Alternative Snap implementation, Redcore provides a solution for Portage issue, elementary OS outlines software centre improvements, Debian publishes install media updates
Canonical, the company behind the Ubuntu distribution, is also the developer of the Snap package format, along with the Snap command line client and official Snap repository. To date, Canonical has insisted on hard-coding the Snap client software to work only with Canonical's own, curated repository of Snap packages. This has put Snap in contrast with the portable Flatpak framework, which works with a variety of third-party repositories. A new project called lol has been created which provides an alternative client for Snap which can work with specified repositories. This could provide people who like using the portable Snap packages with the opportunity to acquire software from Snap repositories other than Canonical's.
* * * * *
The Redcore Linux project has shined a spotlight on a serious package management issue that has surfaced in Gentoo. The issue stems from corruption in the Portage software manager's database which can, in some cases, cause an upgrade to break the operating system. "We have observed in some cases corruption of Portage's internal database (VDB), where the libraries provided by a package are not recorded. This can break the "preserve-libs" functionality, and thus in rare cases break your system during much later updates (even if you do not use 'preserved-libs' now, but decide to switch it on later). The underlying problem occurs usually when glibc has been upgraded to a new major version, but pax-utils has not yet been upgraded to a version compatible with it (but at that moment stays undetected). The full technical details and investigation can be found on a wiki page and on Bugzilla." The Redcore blog post goes on to explain how to address the Portage bug.
* * * * *
The elementary OS team have published a project update which outlines the work they are doing to improve the software centre and desktop experience. Some of the changes to elementary's software centre include improved performance and presenting security and privacy information on an application's summary page. "For example, we've largely reworked the home page with banners featuring the most recently released and updated curated apps in a multi-touch swipable carousel. We've also added up to twelve more of the most recently-updated apps directly below. Rather than just showing the app's icon and name, we now also show each app's summary and an install button - including the developer's recommended price if it's a monetized app. Since we enforce accurate update information for curated apps, this data is populated locally from the apps' AppStream data rather than from a remote API as before. The result of this work is a faster home page with over three times the apps displayed, as well as the ability to purchase or install several apps with far fewer clicks. The categories remain below if you prefer that route for browsing. We've also spent significant time improving individual apps' info pages. Rather than displaying a generic 'explicit' warning dialog when installing an app with certain content warnings, we show this information ahead of time at the top of the page. We differentiate between and inform about several content warnings including things like violence, language, and nudity as well as privacy-related topics like online interactions and data collection."
* * * * *
The Debian project has published updated media for its Stable and Old Stable branches. Versions 10 and 11 of Debian now have refreshed media which includes security updates published since those respective versions were originally launched. "The Debian project is pleased to announce the first update of its stable distribution Debian 11 (codename Bullseye). This point release mainly adds corrections for security issues, along with a few adjustments for serious problems. Security advisories have already been published separately and are referenced where available. Please note that the point release does not constitute a new version of Debian 11 but only updates some of the packages included."
* * * * *
These and other news stories can be found on our Headlines page.
|
| Questions and Answers (by Jesse Smith) |
Benefits to building your own kernel
Tweaking-performance asks: When you install a distro it comes with its own kernel that supports lots of hardware. Would you gain any benefit to building your own kernel with just the drivers you need? Will compiling the kernel give you any performance advantage?
DistroWatch answers: You are correct that Linux distributions ship kernels that support a wide range of hardware. Usually the kernel shipped with a distribution will include as much common hardware support as possible and will be built for the lowest-end processors supported by a given architecture. For instance, an x86_64 build of the kernel will typically run on i3, i5, i7, etc CPUs rather than being optimized for one specific CPU.
Will building your own kernel with support for just your hardware offer a performance boost? It can, in some ways. Compiling a kernel for your specific CPU will allow the kernel to make use of instructions or features of the CPU to run a little more efficiently. The benefits of this will be small, but may be noticeable under heavy workloads. Day to day you probably won't notice a difference because most desktop and server computers spend a lot of their time idle anyway, so you're only likely to see the benefits of a performance boost when doing large batch jobs or gaming. The kernel may also end up being a little smaller in memory, though probably not enough for you to notice a difference.
The biggest change will probably be the amount of disk space consumed by the kernel modules. Most driver support built into Linux is stored in modules which are only loaded into memory when needed. This means your distribution's generic kernel ships with a big group of modules that usually just sit on the disk and never get used. How much space do these modules take up? It will vary from one system to another, but on one distribution I checked this week the modules took up about 250MB of disk space. Most of these will never be loaded into memory and so won't affect performance or memory consumption, but they do consume a bit of disk which could be avoided if I'd compiled my own kernel.
In short, you can get small improvements in kernel performance by building your own. You probably won't see a big difference, maybe just a few percentage points in gain, in most situations, but you can squeeze a little more performance from a custom kernel.
Most people don't compile their own kernels because it's a relatively long process that involves some technical knowledge and offers minor benefits. Usually you'll gain more of a boost by disabling unneeded background services, running a lighter desktop environment, or preloading applications you use regularly into RAM. These will be easier tasks which should offer larger performance gains. However, if you've done those already and still want to explore building your own kernel (for fun and performance perks) you can follow this tutorial on Linux.com which explains the steps.
* * * * *
Additional answers can be found in our Questions and Answers archive.
|
| Released Last Week |
IPFire 2.27 Core 160
IPFire is a Linux distribution that focuses on easy setup, good handling and high level of security, intended for use in firewalls and routers. The project has published a new update which focuses on improving network throughput. "In recent days and months, the development team has spent a lot of time on finding bottlenecks and removing those. Our goal is to increase throughput on hardware and bringing latency down, for a faster network. This update brings a first change which will enable network interfaces that support it, to send packets that belong to the same stream to the same processor core. This allows taking advantage of better cache locality and the firewall engine as well as the Intrusion Prevention System benefit from this, especially with a large number of connections and especially on hardware with smaller CPU caches." The IPFire team is also continuing their work to remove Python 2 from their distribution. Additional information is provided in the project's release announcement.
Feren OS 2021.10
Feren OS is a desktop Linux distribution based on Ubuntu and featuring the KDE Plasma desktop. The project's latest snapshot is Feren OS 2021.10 which includes a new lock screen, new splash screen, and a customized Firefox experience. "The once scrapped configuration for Firefox has now made its way, now repurposed and improved for normal browser usage, into Firefox in Feren OS, both via a new package called firefox-config-feren, and an update to Web Browser Manager that now pre-installs this configuration of Firefox alongside the browser itself, effective starting Feren OS 2021.10. Enjoy Mozilla Firefox, now with: Compact Mode and no titlebar by default. None of that Stories stuff in New Tab (and other New Tab distractions). No Pocket by default. Library being in the toolbar (as was intended by Mozilla themselves during early Proton design ideas) instead of Pocket's button. Most, if not all, the Telemetry values being off, including the ones you can't change via Settings. Home button in the toolbar by default. Skipped Welcome Screens to allow you to get right into the action.... Additional information is provided in the project's release announcement.
Feren OS 2021.10 -- Running the KDE Plasma desktop
(full image size: 2.1MB, resolution: 1920x1080 pixels)
Redo Rescue 4.0.0
Zebradots Software has announced the release of Redo Rescue 4.0.0, a major update of the project's specialist distribution for bare metal backups and system restoration tasks. Although the version number does not indicate it, the release is considered beta quality software, the first build based on Debian 11 "Bullseye": "This is a beta release based on Debian 11. For this major upgrade, the only change applied is the base operating system and any package requirements required to complete the migration to Debian 'Bullseye'. The underlying application and all functionality remains identical to the last release (3.0.2). Please note that newer packages, particularly Partclone or sfdisk, may contain breaking changes we are not aware of. Many (if not most) of the issues reported with the 3.0 releases were focused on the Debian 10's lack of support in the kernel for more recent hardware, which shows a login prompt instead of the GUI. We are hoping this release based on Debian 11 will fix these issues for the majority of users. Here is the brief release announcement as published on the project's GitHub page.
* * * * *
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,621
- Total data uploaded: 40.4TB
|
| Upcoming Releases and Announcements |
|
Summary of expected upcoming releases
|
| Opinion Poll (by Jesse Smith) |
Would you use Snap if it connected to a community repository?
In our News section this week we shared a report that an alternative version of the Snap software is being developed which allows users to pull from Snap package repositories other than the one controlled by Canonical. To date, Canonical has set up the Snap client to pull packages from only their own, proprietary Snap server with its curated repository. For years the Linux community has been lobbying for the ability to set up third-party repositories of Snap packages and it looks like the lol software will finally allow this to happen.
Now that it should be possible to set up community repositories for Snap packages, does this change your view of Snap? Are you more likely to adopt Snap packages if multiple repositories become available?
You can see the results of our previous poll on using multi-machine management tools such as Ansible in last week's edition. All previous poll results can be found in our poll archives.
|
Are you more likely to use Snap now that third-party repositories are possible?
| Are you more likely to use Snap now that third-party repositories are possible?|I already use Snap: | 227 (12%) |
| I did not use Snap but will now: | 67 (3%) |
| I will continue to avoid Snap: | 1341 (69%) |
| Undecided: | 322 (16%) |
|
|
| Website News |
Refreshing package download links
One of our long-running features is the DistroWatch Tracked Packages Collection. We maintain a list of 226 popular utilities, desktop environments, compilers, and desktop applications. These 226 packages are tracked across each Linux distribution and we publish links to the latest stable versions of these packages on our front page when new releases become available.
We believe this list of software is helpful, not only to people looking to discover some of the more powerful programs Linux has to offer, but also to help people keep abreast of changes to their favourite applications.
Twenty years ago, back when we first started tracking these packages and publishing links to the latest source code on our front page, the FTP protocol was still one of the more popular (and reliable) ways to transfer files across the Internet. Over the years FTP has gradually fallen out of favour and most projects these days publish web links using the HTTP protocol. Still, the old FTP links continued to work and so they were left in place.
This past year some of the larger browsers - such as Firefox, Chrome, and Brave - have announced plans to remove support for the FTP protocol. In short, this meant that the FTP links on our Packages page would no longer work in those browsers. In order to change with the times, we have gone through our Packages database and upgraded the lingering FTP links to use the newer HTTP (or HTTPS where available) protocols.
There are still five projects which insist on using FTP exclusively and/or do not provide direct links to source packages over the newer protocols. In these cases we have had to keep the old FTP links which should still work with file transfer clients such as FileZilla. In a few instances projects do provide HTTP download options, just not direct URLs. Visiting main website of a project which still uses FTP will sometimes provide alternative HTTP downloads through redirects which will work in the modern versions of mainstream web browsers.
* * * * *
DistroWatch database summary
* * * * *
This concludes this week's issue of DistroWatch Weekly. The next instalment will be published on Monday, 18 October 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: 0, value: US$0.00) |
|
|
|
 bc1qtede6f7adcce4kjpgx0e5j68wwgtdxrek2qvc4  lnurl1dp68gurn8ghj7ampd3kx2ar0veekzar0wd5xjtnrdakj7tnhv4kxctttdehhwm30d3h82unvwqhhxarpw3jkc7tzw4ex6cfexyfua2nr  86fA3qPTeQtNb2k1vLwEQaAp3XxkvvvXt69gSG5LGunXXikK9koPWZaRQgfFPBPWhMgXjPjccy9LA9xRFchPWQAnPvxh5Le paypal.me/distrowatchweekly • patreon.com/distrowatch |
|
| Linux Foundation Training |
|
| Reader Comments • Jump to last comment |
1 • Snap-Crap (by Bob on 2021-10-11 00:26:55 GMT from United States)
I will continue to avoid Snap.
I won't even buy Cheez-It Snap'd crackers.
2 • "Are you more likely to use Snap now that third-party repositories are possible? (by R. Cain on 2021-10-11 00:27:30 GMT from United States)
There are times when a one-word answer says far more than more words ever could.
I would have preferred for one of the choices to have been
"No".
3 • Snaps (by Shawn Rogers on 2021-10-11 00:58:58 GMT from United States)
I won't use snaps because each installed package has to be mounted as a block device to run. There are as many as 2-3 mounted loop devices for each snap package cluttering up my lsblk and fdisk outputs. How many block devices would you have mounted if the whole system was snaps?
4 • Snap & the kernel (by vern on 2021-10-11 01:30:04 GMT from United States)
I go Snapless. Is that lol as in laughting-out-loud? If so, that's how I view any Snap distribution.
I feel the same regarding building, compiling the kernel. I did it a few times. Not much gain. I also feel I gain from removing needless services.
5 • Pyabr - 100% cpu, no process monitoring (by Andy Prough on 2021-10-11 01:33:40 GMT from Switzerland)
Got to wonder how much digital coin mining you did without knowing it while you tried that distro out Jesse.
That's a pretty funny experience to read about.
As for snaps - I have a funny feeling that "I will continue to avoid" is somehow going to be the runaway winner.
6 • No to Snap! (by Torsten on 2021-10-11 01:45:33 GMT from Germany)
Snap is crap! So, no!
7 • Linux kernel, from source, self-compiled, or other? (by Greg Zeng on 2021-10-11 02:05:26 GMT from Australia)
The newest Linux kernels are released every day, as raw source code, by "The Linux Foundation". These releases are usually bug-fixes & optimizations on previous releases of earlier versions of the Kernel.
The very latest & newest kernel has included some source code injected by commercial products, such as Microsoft, Intel, AMD, Samsung, etc. These lines of source code can be removed, as necessary.
These source codes can then be selected with various compromises & optimization types: different hardware settings, for speed, power efficiencies. Ubuntu (different from Canonical & Red Hat, as organizations) releases it's compiled versions of the source code, with additions added, that are not included in the official source code from The Linux Foundation. Ubuntu offers the compiled code for the main few CPU types in either "normal" or as "low latency". There seems to be no independent bench tests on the difference between these two different kernels.
This compiled code from Ubuntu is released seconds after the raw source code is openly publicly released. Only certain versions of the Ubuntu compilations are officially added into the complete Ubuntu family operating systems.
Red Hat & other operating systems offer only a very small percentage of the available kernels. Many private compiled codes add or remove sections that may or may not be described publicly.
All the Ubuntu & most Debian based operating systems can use any of the pre-compiled kernels offered by the official Ubuntu web site. Some non-Ubuntu systems also offer some kernels from this web site.
Self-compiling source code requires skill, time and enough computer power, so most users prefer pre-compiled code. The extreme very latest code generally is not needed by most users. The system update processes generally cannot keep pace with the very latest releases.
8 • Compiling a kernel (by Gary W on 2021-10-11 02:08:28 GMT from Australia)
I haven't done this for probably 20 years. To suit a machine with 16 meg (not gig) of RAM. After several attempts to remove enough (but not too much), I had a working custom kernel which saved 1 megabyte. A noticeable improvement on this machine, but significantly not worth it on any more capable system. So, never again :-)
As for snaps, not today thanks!
9 • Snap, flatpak or any other shit? (by Jyrki on 2021-10-11 03:44:03 GMT from Czechia)
No, thank you. I am happy with status quo and what my distro offer
10 • Compiling Kernel and Gentoo News Item (by Andy Figueroa on 2021-10-11 03:54:57 GMT from United States)
I run Gentoo on my main desktop so configuring and compiling the kernel has been routine for about 17 years. But, if I was running another distribution with no kernel/driver issues, I would not configure and compile a custom kernel. All binary distributions represent compromises across the board in both kernel and userland, so it's not worth the chase to try to optimize just the kernel. Most mainstream distributions ship satisfactory kernels that support most hardware out-of-the-box.
Cribbing off of a Redcore announcement in order to publicize an issue in Gentoo Portage that was announced directly by Gentoo in a news feed seems like sniping. The original news item which is duplicated in the Redcore announcement is found at: https://www.gentoo.org/support/news-items/2021-09-29-possible-failure-to-preserve-libraries.html
11 • Snap?, LOL (by nsp0323 on 2021-10-11 04:39:03 GMT from Sweden)
Visiting lol repository will show, "Archived project! Repository and other project resources are read-only".
So much for an alternative. Not that I care, would never use it anyway.
12 • snap (by dave on 2021-10-11 05:03:06 GMT from United States)
What we need is a super bloated, er I mean 'fortified' Gnome Shell fork called Crackle so we can have Snap, Crackle, Pop!_OS
Please somebody do this
13 • Snap (by T-Khan on 2021-10-11 05:26:48 GMT from Russia)
The real problem for me with snaps are forced updates. So, no.
14 • I left Ubuntu Mate because of snap (by Mahmut Erogul on 2021-10-11 09:24:08 GMT from Turkey)
having a filesystem with duplicates of libraries for distributions main applications (sound, wellcome, application store) made me mad and I left Ubuntu Mate, moved to Linux Mint; then to Manjaro (uninstalled snap). I will NEVER use snap, it is a conceptual mistake, Canonicals attitude of forcing the users to snap will backfire them.
15 • Snap (by Nerone on 2021-10-11 09:55:54 GMT from Italy)
I don't use Snap or Flatpak. I find Appimage applications useful in some cases.
16 • snap (by geppo on 2021-10-11 10:41:44 GMT from Italy)
snap works really really bad, totally unuseful for me
17 • Snaps (by James on 2021-10-11 11:05:33 GMT from United States)
3 • Snaps (by Shawn Rogers "I won't use snaps because each installed package has to be mounted as a block device to run. There are as many as 2-3 mounted loop devices for each snap package cluttering up my lsblk and fdisk outputs. How many block devices would you have mounted if the whole system was snaps?" Amen to that!
14 • I left Ubuntu Mate because of snap. Me too!
18 • Gentoo distribution kernels (by kernel compiler on 2021-10-11 11:49:00 GMT from Germany)
With Gentoo it was always necessary to compile the Linux kernel. Gentoo used to offer only two options: completely manual (which sounds harder than it is), or by means of the "genkernel" tool.
Lately Gentoo also offers "distribution kernels" as a source package. It makes installing a kernel as simple as any other Gentoo package. It requires no specific knowledge to compile your own kernel this way.
19 • Snap poll (by Otis on 2021-10-11 11:59:35 GMT from United States)
Thanks for "undecided." I have no idea the relative benefits or issues at hand about snap. All I know is it's developed by Canonical, so that seems like the best reason to not have it. As far as I know, MX Linux, my main distro, does not deploy snap (or systemd).
20 • Upcoming Releases (by Beastie on 2021-10-11 12:12:38 GMT from Switzerland)
There's an error in the Upcoming Releases section: FreeBSD 12.2 was released last year, the version to be released in December is 12.3.
21 • Compling kernels and SNAPS (by Tricyx on 2021-10-11 12:25:02 GMT from United States)
I only compile occasionally, more to see what is/is not included. It's also nice to remove bluetooth; wireless; WAN; wacom; etc... hardware modules that seem to be added as the default built in or moduled anymore. Little nuts that some of that is included for a desktop machine that's hardwired.
20 years ago, we didn't have the optimized pre-built options we have today. Between Zen; PF; low-latency; xanmod; hardened; etc... kernels, you can find one that suites your needs and don't really need to compile from source, unless either 1) you really want to 2) something very specific applies to your system 3) save space.
As for Snaps, I haven't had a single good experience with them. Even on Ubuntu Server, all it does is chew up ram and forces you into an architecture you don't want (I like to compare it to Cortana; XBox; or touch features on Windows Server editions). One of the first things I do: apt remove --purge snapd. Flatpak and Appimage are significantly more fleshed out, and here's hoping Canonical realizes it's not worth it and goes the way of Unity.
22 • SNAPS (by dragonmouth on 2021-10-11 12:42:17 GMT from United States)
In a word - NO!.
It's from Canonical. Enough said.
23 • Snap on Ubuntu (by Fabio on 2021-10-11 13:19:01 GMT from Italy)
As @17 I am annoyed by the block devices cluttering with snap. So
my first action after installing Ubuntu is totally removing snapd from the system.
Conversely I moderately use the Flatpak package. In particular in
Ubuntu 20.04 I use Flatpak to install VLC media player because the official VLC version
in Ubuntu 20.04 has bugs and backporting of a newer version is very difficult.
This is a case in which Flatpak is very useful and running fine
24 • Snap and systemd (by Jesse on 2021-10-11 13:44:42 GMT from Canada)
>> "As far as I know, MX Linux, my main distro, does not deploy snap (or systemd)."
You are mostly correct. MX Linux uses SysV init by default. They do provide systemd for people who want to use it, but the default is to make init SysV init. As a result MX Linux doesn't use Snap packages because the Snap framework requires systemd to be running. If your distribution does not run systemd then you can't make use of Snap packages.
25 • Snaps (by DachshundMan on 2021-10-11 13:55:58 GMT from United Kingdom)
Do not use them unless there is no alternative at all. They are just bloatware. It is partly why I swapped from Ubuntu to Mint, that and Unity were the main deciders.
26 • Snaps (by Mocha on 2021-10-11 14:34:10 GMT from United States)
I think the idea that snaps have, as a somewhat integrated universal package, is a good idea. Their execution, though, is rather poor. It's a touch bloated and it's lockdown by canonical makes it far worse than what it should be. I feel if we branch out, try and make something better, and improve on it's faults, we could have the next appimage. But for now? I'd rather write a new distro by hand than use snaps.
27 • Flat-snap-crap (by Bob on 2021-10-11 15:16:03 GMT from United States)
I browsed Flathub to see if it might be worth a risk. They have a lot of STUFF, but nothing I want.
I tried snap back when Ubuntu abandoned Chromium. Total garbage. Chromium ran poorly, didn't integrate with the gtk theme, AND the snap folder is parked right there in my home directory. WHY? At least put it in the .conf directory!
That snap/Chromium fiasco led me to Brave browser, but I abandoned the deb-ubuntu systems altogether.
Now I'm on Manjaro...everyting I want is there. Perfect.
28 • Snaps and kernel builds (by Donaudumpfschiffarts... on 2021-10-11 15:42:54 GMT from United States)
I've built a few kernels in the past, like 20 yrs ago. But it is a long process, and I get kernel updates often enuf that I don't want to rebuild every time.
As for snaps...that's one of the reasons I left Ubuntu after 10 years. There were several others (like constant paper cuts, apathy, and their dictatorial attitude). I'll use AppImages, but only if I have to. The distros I use now don't seem to have too much problem keeping regular packages in their repos.
Maybe its time we realize that dynamic linking was good for the times, but the times now call for a return to static linking. At least for individual users.
29 • Snaps (by Robert on 2021-10-11 15:47:33 GMT from United States)
While being able to use alternative repositories does raise my opinion of snaps, I still rank it below every other option.
30 • Oh....Snap! (by Mike on 2021-10-11 16:27:29 GMT from United Kingdom)
I purged snapd and Discover support for it from my kubuntu (and neon in VM) system straight after install. I did the same with LVFS as my core system hardware is legacy and if something needs it (newer SSD from crucial for example) I can update manually myself.
It actually makes Discover more responsive not having snap or lvfs enabled so win win.
I'll continue to use the Official Mozilla PPA for Thunderbird as long as it is available, the same goes for LibreOffice Community Fresh.
31 • @24 • Snap and systemd (by Jesse...) (by R. Cain on 2021-10-11 17:21:07 GMT from United States)
"...As a result MX Linux doesn't use Snap packages because the Snap framework requires systemd to be running. If your distribution does not run systemd then you can't make use of Snap packages..."
Clarification, amplification, and the benefit of your expertise are all deeply appreciated.
One more reason to not use any distro which runs systemd Thank you.
32 • @22 • SNAPS (by dragonmouth... (by R. Cain on 2021-10-11 19:47:43 GMT from United States)
"In a word - NO!..."
See comment #2.
33 • Snap (by Elise on 2021-10-11 21:00:18 GMT from Austria)
One reason I love Linux Mint is that instead of following the Ubuntu way, they did not enable Snaps by default, and they did not allow "apt install chromium" to automatically "snap install" Chromium. (How anyone can justify automatically switching "apt install" to "snap install" is beyond comprehension.) Instead, they build their own Chromium package. (And those who want to enable Snaps on Linux Mint can do so.)
34 • Snaps (by Bob McConnell on 2021-10-11 21:57:43 GMT from United States)
It is not even worth considering until it fully supports Slackware and vice versa. I suspect that is not at all likely to happen.
35 • Compiling a Kernel (by crayola eater on 2021-10-11 21:58:34 GMT from United States)
I always told myself that after I retired I would set aside the time to research the hows and build my own kernel. Well, it's now 7 years and counting, and I've moved no closer to that retirement project than any of the others that reside in the closet.
But I still think it would be worth the the time if only for the experience gained.
oh yeah, I vote No to Snaps
36 • Snap (by Mike on 2021-10-11 22:17:29 GMT from United Kingdom)
@33 I was using Linux Mint Cinnamon for some time too and it is still installed on my Mother's PC at present which doesn't appear to suffer the effects of the memory leak my own did. I think it is graphics stack related but you never really know what triggers it, especially when no useful trace from it was ever created even with debug packages installed.
I'm not keen on the plan they have about a preset memory limit for the Cinnamon process which leaks based auto process kill to get round the leak.
If the Linux Mint developers rolled a Plasma ISO I would be on it like a shot. However I am glad they don't really because their speciality and focus should always remain in Cinnamon and it's GTK brethren (MATE and XFCE).
Regarding portable apps - they have embraced Flatpak to a certain extent by publishing their own application Warpinator to it officially.
37 • Compiling and coding. (by Friar Tux on 2021-10-11 22:27:13 GMT from Canada)
@36 (crayola eater) I retired a number of years before I actually retired. I was bored out of my skull, so I went back to work. Then, about 5 years ago, I retired for good. This time I loved it. I had planned a few projects to keep me busy. Got them done the first year. I also had plans to learn to code and build my own systems but that fell by the wayside as being way to redundant and labour intensive. Now I consider myself a "user" (no drugs involved). An artist's work would be useless if no one enjoyed it. An author's writings would be for naught if no one read them. Well, the same goes for coding and compiling, in my opinion. So, I'll use already built OSes and software and such. There is enough repetition of effort in Linux that I don't need to add to it. Now I spend my time playing with the various distros and software to see which one, in my opinion, is REALLY the best. I keep copious note of everything.
38 • SNAP for Me (by MattE on 2021-10-12 01:50:06 GMT from United States)
If it take more than 1 minute to get set up from a normal install or is a general PITA to install, I'll use a snap if available. I'm lazy.
39 • Snap? (by Silent Warrior on 2021-10-12 03:01:05 GMT from Sweden)
To Snap, or not to Snap... I don't really care, honestly. I've heard about some ideological friction between non-Canonical distros and Snap, but for me, personally, I just don't have a use-case where there is a piece (or version) of software I can't find in the normal package database that exists as a Snap. Will consider the question when that situation changes.
('Course, I think my distro straight up blocks Snap now, anyway, so I'd have to go distro-hopping first all the same.)
40 • Pyabr OS Trivia (by Jack on 2021-10-12 08:34:06 GMT from Australia)
The Pyabr OS originated in Iran where Farsi is the official language. The word "abr" means cloud in Farsi. Pyabr is then the equivalent of PyCloud in English.
41 • Snap (by Detmer on 2021-10-12 12:57:54 GMT from Belgium)
Snap? No, thank you. For one thing, snapd has been the laughing stock of software management for several years now. See this bug report (open for five years and counting), especially comment no. 4: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053
For another thing, in the Ubuntu people push the responsibility of making snaps run with acceptable(?) speed to the end users. From the Distrowatch headline quote: "In this article, we want to show you a number of methods and tools you can use to make your snaps snappy." In line with the systemd folks, they sh*t on other peoples desks, then leave the cleaning to those same people.
42 • compiling kernels (by Glenn Condrey on 2021-10-12 13:57:51 GMT from United States)
I compiled my own kernel back when Xandros 3.01 was a thing. It was a mite bit difficult, as they said...that although Xandros was based on Debian...Xandros was NOT Debian...so there were some extra steps involved.
As always...if anything broke in the OS 'broke' while you were compiling things...you got to keep all the pieces.... (meaning you'd have to do an OS re-install.)
As for Snap or Flatpacks, if they make installing a package easier...I'm down for it. I think as they become more common, easier ways to maintain and install will make them more attractive to Linux users than they are now.
43 • Joining the snap dogpile... (by Nathan on 2021-10-12 14:44:44 GMT from United States)
I've used snap for anbox, but being forced to use systemd limits my options, so I abandoned it. It's not that I'm ideological about init software or anything, it's just that being tied to a specific init for something conceptually unrelated is silly. And so, snap goes in my "unportable/distro-specific" mental category, which I realize is precisely the opposite of the cross-platform goals of snap. Ah well.
44 • oh snap (by Tad Strange on 2021-10-12 17:15:53 GMT from Canada)
I run only 1, and only because I'm currently on Kubuntu and that was the simplest way to get this app, so I figured why not.
Once I switch back to Manjaro, or something else non-buntu, I don't know why I'd bother seeking out Snaps when there are better/simpler options.
Maybe someday it will develop into a compelling ecosystem, but I'm certain that it's going to continue being voldemort/systemd to many.
45 • Snap (by AJ Dowell on 2021-10-12 21:40:16 GMT from United States)
I use Snap for Celtx. I'm fine with snaps but whenever possible, I find an alternative. If I can find a .deb, that's what I use. I got tired of editing .py files and dowloading dependencies to get Trelby working properly everytime I updated to a newer Linux OS. I like Celtx and it has other uses than just screenplay writing. I understand there's Lyx with Hollywood script plugin, Libreoffice screenplay template, and so on. Snap makes it simple to get the writing done. My main job is to write. So the answer for me personally is yes to Snaps for now and we will see how it goes later down the road. I would love for someone to make Celtx an AppImage or Trelby into an AppImage.
46 • Snap (by hulondalo on 2021-10-12 21:57:38 GMT from Australia)
snap is unironically inflexible. users'll end up having many copies of same programs like on windows (for instance i now have 5 version of zlib on my pc from total war empire, total war shogun 2, total war rome 2 and total war attila, crusader kings 3; 1 outdated very old python v2 from battlefield 2), wastes more bandwidth and time to update them all, not to mention security concern.
if you want newer software use rolling distros instead. snap is heresy, avoid it if you can.
47 • Celtx and writing apps. (by Mark B on 2021-10-12 22:02:41 GMT from United Kingdom)
@45 I like Celtx too and was disappointed when it moved to subscription model. Since you are a writer you might like the (abandoned but working) Linux version of Scrivener. I have a !licence for the Windows version but use Mint mostly. The program Manuskript looks useful too.
48 • Compiling Kernels (by Eirian on 2021-10-12 23:05:02 GMT from United Kingdom)
For us old timers compiling a kernel with menuconfig was something you did with each new kernel release as there was a must have improvement with each release. It was necessary in the late 1990s to compile the kernel to get printers working and I remember the excitement when the kernel first allowed the use of USB mass storage, but a recompile was required. Compiling a kernel did not require much technical knowledge and did not take too much time even when computers were running off 32MB (not 32GB) of RAM. Modules were a big innovation, but in late 1990s the pre-compiled kernel was monolithic and you had to use menuconfig to switch things you didn't need to M for module. I can't imagine compiling a kernel in an era where Tumbleweed gives you an updated kernel practically every time you update. Maybe if I had kept paying for SuSE boxed editions rather than switching to Debian I might not have had to compile kernels so much. Eventually having to recompile just to use a new printer drove me to switch to Macs, but within a few years I was running Debian PPC on those Macs.
49 • Kernels (by Mike on 2021-10-13 00:03:18 GMT from United Kingdom)
I leave kernels well alone and use what is pre-compiled by the distribution developers (or sourced from upstream repositories by them)
I've always used wired or wireless networked HP laser and inkjet printers and more recently an MFP and never had an issue getting them to print or scan with Linux. More recently the development of driver-less printing has been gathering pace.
Soon all printers regardless of brand should just work at some level with linux, I still prefer the full hplip with GUI package coupled with xsane though and disable ippusbxd and avahi-daemon to avoid persistent duplication of printers.
The only thing I have ever had to do is use kernel boot commands in grub config to address compatibility issues in the past with AMD Kabini when it was still relatively new. Those issues of course were eventually addressed after users including myself reporting them with supporting logs and traces.
50 • Snap, very smart! (or not?) (by Alessandro di Roma on 2021-10-13 08:34:22 GMT from Italy)
Problem: There are N so-called standards! They are too many!
Solution: Let's invent an (N+1)th one!
51 • Snaps (by pepa65 on 2021-10-13 12:55:29 GMT from Thailand)
Hate snaps, if I do install Ubuntu professionally, I remove it. But for personal use I switched from Ubuntu Mate to Mint Mate, Linux Mint explicitly does not integrate snaps.
[As to compiling kernels, did that decades ago, now I don't (need to) bother anymore, too little gain.]
52 • Poll (by Gen 1b on 2021-10-13 22:32:59 GMT from Canada)
In reguards to the poll, I do not use chat programs
53 • Snap alternative (by Otis on 2021-10-13 22:38:39 GMT from United States)
If for various reasons you, like me, don't like the limitations of systemd/snap togetherness.. don't forget about the alternative (with the best name in response to Canonical's tentacles): LOL.
https://gitlab.com/lol-snap/lol
54 • Snap will come (by analogtek on 2021-10-13 23:13:24 GMT from United States)
If the basement boy's want snap to be a standard. It will be a standard. Even if you do not like it-will be.
55 • Snap (by cor on 2021-10-14 03:21:31 GMT from United States)
This is a terrible solution. I absolutely avoid all snaps. I have tried them and found them useless in the limited environment. I would rather compile than be trapped in a snap environment.
56 • lol snap (by Mike on 2021-10-14 08:42:29 GMT from United Kingdom)
@54 that is what is mentioned in this week's distrowatch news. Personally I believe it is a risky proposition as anyone could set up a snap repository and exploit the trust/naivety of people to spread malware for data harvesting (ID or IP theft), ransomware or bitcoin mining.
While the approach Canonical are taking is questionable at best, at least at present there are some code checks in place for any snaps submitted.
I would use Flathub submissions from the genuine developers (Mozilla, VLC, The Document Foundation etc.) over snap still given the choice if no other means of obtaining an application was possible.
I have not tried AppImage yet but probably should check it out too.
57 • Snaps (by LazyBum on 2021-10-14 15:00:21 GMT from United States)
I'll be the voice of dissent here, I love Snaps! Plex was always out of date until I started using the Snap package. I also use a couple of other Snap packages along with some Flatpaks and an appimage for Plexamp. Honestly, I think it's amazing that all these things work (your mileage may vary).
58 • toothpick building with Pyabr (by own worker on 2021-10-15 00:22:41 GMT from France)
"This week we ... look at the unusual Pyabr project. Pyabr seeks to build an operating system ... almost entirely from Python code."
maybe ppl like to do these kinds of projects to demonstrate their skills / create a niche project / get a fan following. IMO Linux is at its best with these kinds of niche & specialized distros. At least they don't copy other ppl's work and just tweak it a little for their own benefit. But if a project is too toothpick-nichie it will probably slowly die.
59 • Linux and its crutches (by whoKnows on 2021-10-15 11:38:54 GMT from Switzerland)
If I've had to write the article about Linux, package management ... AppImage, Flatpak, Snap ... it'd be highly probable beginning somehow like this:
A desperate attempt to turn something useless into something that is still suitable for everyday usage.
Linux on the desktop is a self-inflicted accident, based on a totally broken basic concept ...
60 • *Snap* goes the code (by Cheker on 2021-10-15 13:38:45 GMT from Portugal)
Anything I could've said about Snap was already said, though to be honest my personal experience wasn't super, super bad.
I used the snaps for Brave and Notepadqq on Debian. I gave up on them after repeated failed attempts at giving Notepadqq write permission to essentially everywhere you'd expect to have it. I ditched it for the native Pluma.
As for Brave, it didn't actually give me any problems, it's just that it's my secondary browser that I barely use, I felt it was pointless to keep the snap framework in place just for it, so I ditched it for the native Chromium.
61 • Flutter OS (by erok on 2021-10-15 15:08:50 GMT from United States)
...It's only a matter of time.
I found the concept of a de-branded HP laptop hilarious. Looking at a mint ZE460 that still works and is built great. There's an HP badge in the webcam spot.
62 • Elementary OS (by Hollywood on 2021-10-15 16:00:39 GMT from United States)
I wish they would include an option to disable or at least deley and \ or choose when and how offten the os checks for updates. it is madding at times with how offten it will pop up saying theres an update, after you update the darn thing.
Number of Comments: 62
Display mode: DWW Only • Comments Only • Both DWW and Comments
| | |
| TUXEDO |
TUXEDO Computers - Linux Hardware in a tailor made suite
Choose from a wide range of laptops and PCs in various sizes and shapes at TUXEDOComputers.com. Every machine comes pre-installed and ready-to-run with Linux. Full 24 months of warranty and lifetime support included!
Learn more about our full service package and all benefits from buying at TUXEDO.
|
| Archives |
| • Issue 1048 (2023-12-04): openSUSE MicroOS, the transition from X11 to Wayland, Red Hat phasing out X11 packages, UBports making mobile development easier |
| • Issue 1047 (2023-11-27): GhostBSD 23.10.1, Why Linux uses swap when memory is free, Ubuntu Budgie may benefit from Wayland work in Xfce, early issues with FreeBSD 14.0 |
| • Issue 1046 (2023-11-20): Slackel 7.7 "Openbox", restricting CPU usage, Haiku improves font handling and software centre performance, Canonical launches MicroCloud |
| • Issue 1045 (2023-11-13): Fedora 39, how to trust software packages, ReactOS booting with UEFI, elementary OS plans to default to Wayland, Mir gaining ability to split work across video cards |
| • Issue 1044 (2023-11-06): Porteus 5.01, disabling IPv6, applications unique to a Linux distro, Linux merges bcachefs, OpenELA makes source packages available |
| • Issue 1043 (2023-10-30): Murena Two with privacy switches, where old files go when packages are updated, UBports on Volla phones, Mint testing Cinnamon on Wayland, Peppermint releases ARM build |
| • Issue 1042 (2023-10-23): Ubuntu Cinnamon compared with Linux Mint, extending battery life on Linux, Debian resumes /usr merge, Canonical publishes fixed install media |
| • Issue 1041 (2023-10-16): FydeOS 17.0, Dr.Parted 23.09, changing UIDs, Fedora partners with Slimbook, GNOME phasing out X11 sessions, Ubuntu revokes 23.10 install media |
| • Issue 1040 (2023-10-09): CROWZ 5.0, changing the location of default directories, Linux Mint updates its Edge edition, Murena crowdfunding new privacy phone, Debian publishes new install media |
| • Issue 1039 (2023-10-02): Zenwalk Current, finding the duration of media files, Peppermint OS tries out new edition, COSMIC gains new features, Canonical reports on security incident in Snap store |
| • Issue 1038 (2023-09-25): Mageia 9, trouble-shooting launchers, running desktop Linux in the cloud, New documentation for Nix, Linux phasing out ReiserFS, GNU celebrates 40 years |
| • Issue 1037 (2023-09-18): Bodhi Linux 7.0.0, finding specific distros and unified package managemnt, Zevenet replaced by two new forks, openSUSE introduces Slowroll branch, Fedora considering dropping Plasma X11 session |
| • Issue 1036 (2023-09-11): SDesk 2023.08.12, hiding command line passwords, openSUSE shares contributor survery results, Ubuntu plans seamless disk encryption, GNOME 45 to break extension compatibility |
| • Issue 1035 (2023-09-04): Debian GNU/Hurd 2023, PCLinuxOS 2023.07, do home users need a firewall, AlmaLinux introduces new repositories, Rocky Linux commits to RHEL compatibility, NetBSD machine runs unattended for nine years, Armbian runs wallpaper contest |
| • Issue 1034 (2023-08-28): Void 20230628, types of memory usage, FreeBSD receives port of Linux NVIDIA driver, Fedora plans improved theme handling for Qt applications, Canonical's plans for Ubuntu |
| • Issue 1033 (2023-08-21): MiniOS 20230606, system user accounts, how Red Hat clones are moving forward, Haiku improves WINE performance, Debian turns 30 |
| • Issue 1032 (2023-08-14): MX Linux 23, positioning new windows on the desktop, Linux Containers adopts LXD fork, Oracle, SUSE, and CIQ form OpenELA |
| • Issue 1031 (2023-08-07): Peppermint OS 2023-07-01, preventing a file from being changed, Asahi Linux partners with Fedora, Linux Mint plans new releases |
| • Issue 1030 (2023-07-31): Solus 4.4, Linux Mint 21.2, Debian introduces RISC-V support, Ubuntu patches custom kernel bugs, FreeBSD imports OpenSSL 3 |
| • Issue 1029 (2023-07-24): Running Murena on the Fairphone 4, Flatpak vs Snap sandboxing technologies, Redox OS plans to borrow Linux drivers to expand hardware support, Debian updates Bookworm media |
| • Issue 1028 (2023-07-17): KDE Connect; Oracle, SUSE, and AlmaLinux repsond to Red Hat's source code policy change, KaOS issues media fix, Slackware turns 30; security and immutable distributions |
| • Issue 1027 (2023-07-10): Crystal Linux 2023-03-16, StartOS (embassyOS 0.3.4.2), changing options on a mounted filesystem, Murena launches Fairphone 4 in North America, Fedora debates telemetry for desktop team |
| • Issue 1026 (2023-07-03): Kumander Linux 1.0, Red Hat changing its approach to sharing source code, TrueNAS offers SMB Multichannel, Zorin OS introduces upgrade utility |
| • Issue 1025 (2023-06-26): KaOS with Plasma 6, information which can leak from desktop environments, Red Hat closes door on sharing RHEL source code, SUSE introduces new security features |
| • Issue 1024 (2023-06-19): Debian 12, a safer way to use dd, Debian releases GNU/Hurd 2023, Ubuntu 22.10 nears its end of life, FreeBSD turns 30 |
| • Issue 1023 (2023-06-12): openSUSE 15.5 Leap, the differences between independent distributions, openSUSE lengthens Leap life, Murena offers new phone for North America |
| • Issue 1022 (2023-06-05): GetFreeOS 2023.05.01, Slint 15.0-3, Liya N4Si, cleaning up crowded directories, Ubuntu plans Snap-based variant, Red Hat dropping LireOffice RPM packages |
| • Issue 1021 (2023-05-29): rlxos GNU/Linux, colours in command line output, an overview of Void's unique features, how to use awk, Microsoft publishes a Linux distro |
| • Issue 1020 (2023-05-22): UBports 20.04, finding another machine's IP address, finding distros with a specific kernel, Debian prepares for Bookworm |
| • Issue 1019 (2023-05-15): Rhino Linux (Beta), checking which applications reply on a package, NethServer reborn, System76 improving application responsiveness |
| • Issue 1018 (2023-05-08): Fedora 38, finding relevant manual pages, merging audio files, Fedora plans new immutable edition, Mint works to fix Secure Boot issues |
| • Issue 1017 (2023-05-01): Xubuntu 23.04, Debian elects Project Leaders and updates media, systemd to speed up restarts, Guix System offering ground-up source builds, where package managers install files |
| • Issue 1016 (2023-04-24): Qubes OS 4.1.2, tracking bandwidth usage, Solus resuming development, FreeBSD publishes status report, KaOS offers preview of Plasma 6 |
| • Issue 1015 (2023-04-17): Manjaro Linux 22.0, Trisquel GNU/Linux 11.0, Arch Linux powering PINE64 tablets, Ubuntu offering live patching on HWE kernels, gaining compression on ex4 |
| • Issue 1014 (2023-04-10): Quick looks at carbonOS, LibreELEC, and Kodi, Mint polishes themes, Fedora rolls out more encryption plans, elementary OS improves sideloading experience |
| • Issue 1013 (2023-04-03): Alpine Linux 3.17.2, printing manual pages, Ubuntu Cinnamon becomes official flavour, Endeavour OS plans for new installer, HardenedBSD plans for outage |
| • Issue 1012 (2023-03-27): siduction 22.1.1, protecting privacy from proprietary applications, GNOME team shares new features, Canonical updates Ubuntu 20.04, politics and the Linux kernel |
| • Issue 1011 (2023-03-20): Serpent OS, Security Onion 2.3, Gentoo Live, replacing the scp utility, openSUSE sees surge in downloads, Debian runs elction with one candidate |
| • Issue 1010 (2023-03-13): blendOS 2023.01.26, keeping track of which files a package installs, improved network widget coming to elementary OS, Vanilla OS changes its base distro |
| • Issue 1009 (2023-03-06): Nemo Mobile and the PinePhone, matching the performance of one distro on another, Linux Mint adds performance boosts and security, custom Ubuntu and Debian builds through Cubic |
| • Issue 1008 (2023-02-27): elementary OS 7.0, the benefits of boot environments, Purism offers lapdock for Librem 5, Ubuntu community flavours directed to drop Flatpak support for Snap |
| • Issue 1007 (2023-02-20): helloSystem 0.8.0, underrated distributions, Solus team working to repair their website, SUSE testing Micro edition, Canonical publishes real-time edition of Ubuntu 22.04 |
| • Issue 1006 (2023-02-13): Playing music with UBports on a PinePhone, quick command line and shell scripting questions, Fedora expands third-party software support, Vanilla OS adds Nix package support |
| • Issue 1005 (2023-02-06): NuTyX 22.12.0 running CDE, user identification numbers, Pop!_OS shares COSMIC progress, Mint makes keyboard and mouse options more accessible |
| • Issue 1004 (2023-01-30): OpenMandriva ROME, checking the health of a disk, Debian adopting OpenSnitch, FreeBSD publishes status report |
| • Issue 1003 (2023-01-23): risiOS 37, mixing package types, Fedora seeks installer feedback, Sparky offers easier persistence with USB writer |
| • Issue 1002 (2023-01-16): Vanilla OS 22.10, Nobara Project 37, verifying torrent downloads, Haiku improvements, HAMMER2 being ports to NetBSD |
| • Issue 1001 (2023-01-09): Arch Linux, Ubuntu tests new system installer, porting KDE software to OpenBSD, verifying files copied properly |
| • Issue 1000 (2023-01-02): Our favourite projects of all time, Fedora trying out unified kernel images and trying to speed up shutdowns, Slackware tests new kernel, detecting what is taking up disk space |
| • Issue 999 (2022-12-19): Favourite distributions of 2022, Fedora plans Budgie spin, UBports releasing security patches for 16.04, Haiku working on new ports |
| • Issue 998 (2022-12-12): OpenBSD 7.2, Asahi Linux enages video hardware acceleration on Apple ARM computers, Manjaro drops proprietary codecs from Mesa package |
| • Issue 997 (2022-12-05): CachyOS 221023 and AgarimOS, working with filenames which contain special characters, elementary OS team fixes delta updates, new features coming to Xfce |
| • Issue 996 (2022-11-28): Void 20221001, remotely shutting down a machine, complex aliases, Fedora tests new web-based installer, Refox OS running on real hardware |
| • Issue 995 (2022-11-21): Fedora 37, swap files vs swap partitions, Unity running on Arch, UBports seeks testers, Murena adds support for more devices |
| • Issue 994 (2022-11-14): Redcore Linux 2201, changing the terminal font size, Fedora plans Phosh spin, openSUSE publishes on-line manual pages, disabling Snap auto-updates |
| • Full list of all issues |
| Star Labs |
Star Labs - Laptops built for Linux.
View our range including the highly anticipated StarFighter. Available with coreboot open-source firmware and a choice of Ubuntu, elementary, Manjaro and more. Visit Star Labs for information, to buy and get support.
|
| Shells.com |
Your own personal Linux computer in the cloud, available on any device. Supported operating systems include Android, Debian, Fedora, KDE neon, Kubuntu, Linux Mint, Manjaro and Ubuntu, ready in minutes.
Starting at US$4.95 per month, 7-day money-back guarantee
|
| Random Distribution | 
Debris Linux
Debris Linux was a minimalist, desktop-oriented distribution and live CD based on Ubuntu. It includes the GNOME desktop and a small set of popular desktop applications, such as GNOME Office, Firefox web browser, Pidgin instant messenger, and ufw firewall manager. Debris Linux ships with a custom kernel, a custom system installer called DebI, and a script that makes it easy to save and restore any customisations made while in live mode.
Status: Discontinued
|
| TUXEDO |
TUXEDO Computers - Linux Hardware in a tailor made suite
Choose from a wide range of laptops and PCs in various sizes and shapes at TUXEDOComputers.com. Every machine comes pre-installed and ready-to-run with Linux. Full 24 months of warranty and lifetime support included!
Learn more about our full service package and all benefits from buying at TUXEDO.
|
| Star Labs |
Star Labs - Laptops built for Linux.
View our range including the highly anticipated StarFighter. Available with coreboot open-source firmware and a choice of Ubuntu, elementary, Manjaro and more. Visit Star Labs for information, to buy and get support.
|
|
• 
• 
• 
• 
• 
• 
• 
