 DistroWatch Weekly |
| DistroWatch Weekly, Issue 881, 31 August 2020 |
Welcome to this year's 35th issue of DistroWatch Weekly!
Choosing the proper operating system settings is always a balancing act between features, security, and performance. Do we want powerful desktop environments with all the bells and whistles or a minimal window manager? Do we want slick, graphical configuration tools or to manage everything through efficient text files? Should a filesystem be fast and simple, or robust and offer lots of options? These are choices developers and users need to make on a regular basis. We begin this week with a look at a distribution called BunsenLabs Linux that takes a minimal approach, combining a minimal Debian base with the lightweight Openbox window manager. Read on to find out how BunsenLabs performs. In our News section we share a link to DragonFly's new ePUB version of the operating system's Handbook along with news of openSUSE's Jump edition. Then we report on Fedora and FreeBSD making updates to their filesystems, with both focusing on new features through the advanced ZFS and Btr filesystems. What do you think of Fedora's move to shift from the classic ext4 filesystem to the more advanced Btrfs? Let us know in our Opinion Poll. A few weeks ago we discussed the benefits and drawbacks of dynamic linking applications versus statically linking libraries. In our Questions and Answers column we take a deeper dive into the storage space required to hold applications using these two approaches to linking. Plus we are pleased to share the releases of the past week and link to the torrents we are seeding. We wish you all a wonderful week and happy reading!
Content:
- Review: BunsenLabs Linux Lithium
- News: Fedora plans to make Btrfs the default filesystem, FreeBSD imports new OpenZFS code, DragonFly BSD publishes documentation in ePUB format, openSUSE presents Jump edition
- Questions and answers: More information about dynamic versus static linking
- Released last week: Tails 4.10, Parted Magic 2020_08_23
- Torrent corner: Bluestar, ExTiX, MidnightBSD, KDE neon, Nitrux, Raspberry Pi OS, Septor, Tails
- Opinion poll: Fedora adopting Btrfs as the default filesystem
- Reader comments
Listen to the Podcast edition of this week's DistroWatch Weekly in OGG (16MB) and MP3 (12MB) formats.
|
| Feature Story (by Jesse Smith) |
BunsenLabs Linux Lithium
BunsenLabs Linux is a distribution offering a lightweight and easily customizable Openbox desktop. The BunsenLabs distribution is based on Debian's Stable branch which gives the project access to a vast collection of software packages.
Bunsen's latest release is called Lithium (the project uses element names in place of version numbers) and is based on Debian 10 "Buster". Lithium now automatically updates the application menu when new software is installed and includes a range of Broadcom wireless drivers to help users get on-line. The distribution now ships with a dark theme by default and the project's welcome window script has been streamlined to get the system up and running faster. Bunsen should now work with Secure Boot systems.
BunsenLabs is available in two builds. One is a 1.2GB ISO file for 64-bit (x86_64) computers while the other is a 651MB ISO for 32-bit systems. The second ISO is quite a bit smaller in order to allow it to fit on a CD. Booting from the project's install media brings up a menu asking if we would like to boot into a live desktop environment or launch the system installer. The live mode is available in three flavours (normal, failsafe, and running from RAM) while the installer can be launched in graphical or text mode.
Taking the live option brings up a graphical desktop, powered by the Openbox window manager. Once we arrive at the desktop a welcome window appears. This window gives us a few quick tips on using desktop shortcut keys, provides us with the live environment's password, and tells us how to use the command line to change our keyboard's layout. We are also told we can quickly access the application menu by right-clicking on the desktop. Finally, we are told that to run the system installer we need to restart the computer and select an install option from the boot menu; the installer is not available through the live session.
BunsenLabs Lithium -- The initial welcome window
(full image size: 128kB, resolution: 1280x1024 pixels)
Exploring the Openbox interface we find a Conky status panel to the right of the screen. This panel shows us some system statistics such as our CPU usage, memory consumption, and uptime. A list of desktop shortcuts is also shown toward the bottom of the panel and these provide us with quick access to popular applications and actions. Another panel, placed along the bottom of the screen, hosts the application menu, task switcher, and system tray. The desktop is mostly dark and uses blue or white text on a black background in most situations.
Installer
After playing around with Bunsen's live mode a bit to confirm it was generally working as expected, I restarted the computer and launched the graphical installer. BunsenLabs uses Debian's installer and, as far as I can tell, there is no practical difference between what Bunsen uses and what Debian ships. I covered Debian's install process last year. The installer walks us through the usual steps of picking our preferred language, our location, creating a user account, confirming our time zone, and partitioning the disk. We can use manual or guided partitioning from within the installer. The manual option is quite flexible, if a bit cumbersome. The guided option will set up an ext4 root filesystem and a swap partition. Once the installer finishes copying its files to our hard drive it automatically reboots the computer.
Early impressions
When BunsenLabs boots it brings up a graphical login screen. Signing into our account launches Openbox and brings up a second welcome window. This new window beings with a greeting and then offers to walk us through customising the operating system. Our first step is to provide our password for sudo/administrative access. Then we are asked if we want to download package upgrades. In my case there were 36 updates, totalling about 136MB in size. We are then given the chance to enable backports repositories in order to gain access to newer versions of applications.
BunsenLabs Lithium -- Customising the operating system through the welcome window
(full image size: 117kB, resolution: 1280x1024 pixels)
The welcome window then offers to enable Bluetooth support, install Java, install Flash plugins, and install Dropbox. We are also given the chance to install optional development tools. The welcome window concludes by showing us links to on-line assistance and shows us the command we can use to run the welcome script again.
The welcome window does not take particularly long to get through and offers some useful options. I think, perhaps, it would have been nice if the script had collected all my answers first and then performed its tasks at the end, that way I would not need to wait while new packages were fetched. However, other than that, the script does its job well. Each step is explained clearly and provides a simple yes/no prompt.
Hardware
I tested BunsenLabs in a virtual machine first, trying it out in VirtualBox. The distribution performed well, operating smoothly and quickly in the virtual environment. My only issue was the Openbox interface would not resize dynamically with the VirtualBox window and the display configuration tools did not seem to be able to work with higher resolutions.
When I switched to running Bunsen on my workstation the system performed well. My screen's full resolution was used, the distribution ran quickly, and the interface was responsive. Media keys worked on my keyboard, which was nice. There were a few times when the distribution paused while starting up or shutting down, but it always worked itself out eventually.
BunsenLabs Lithium -- Running the Firefox web browser
(full image size: 135kB, resolution: 1280x1024 pixels)
Bunsen was relatively light on resources. The distribution consumed 375MB of RAM when logged into Openbox, and took up 3.8GB of disk space. The distribution generally did not use much of my CPU, making it pleasantly lean.
Included applications
Digging through Bunsen's application menu we find a large, sprawling tree of options. There are a lot of sub-menus and then sub-sub-menus. Some applications are listed under their name while other entries describe a task. For instance, there are entries for a Web Browser and File Manager, while other programs are listed as LibreOffice or HexChat. There are several menu entries listed as simply "File Manager". A few of these open the Thunar manager while one opens the program's settings panel. Another quirk of the menu is a number of items are listed with a BunsenLabs (BL) prefix. These are not BunsenLabs-specific applications, so I'm unsure why they get the special prefix. For example, "BL Media Player" is the popular VLC player while "BL Text Editor" is the Geany editor.
BunsenLabs Lithium -- The application menu listing multiple File Manager entries
(full image size: 101kB, resolution: 1280x1024 pixels)
There are a surprisingly large number of entries, though a fairly small number of applications. I found the Firefox web browser, the Transmission bittorrent client, the HexChat IRC client, and the Xfburn disc burning software. LibreOffice and the Evince document viewer are installed for us, along with the VLC media player. Geany is available to edit text files and Htop is present to monitor system resources. There is a menu entry called Mail Reader, though no e-mail client is installed. In the background Bunsen uses the systemd init software and runs on version 4.19 of the Linux kernel.
Bunsen ships with a lot of little configuration tools. These items help tweak the look of the desktop, change themes, adjust the number of virtual desktops (the default is two), and adjust the panel. The configuration tools sometimes have short, cryptic launcher names, such as "Tint2" and "gmrun". This can make it difficult for people unfamiliar with the names of specific desktop components to find what they want to adjust.
BunsenLabs Lithium -- Two of the distribution's settings modules
(full image size: 109kB, resolution: 1280x1024 pixels)
The application menu also contains a bunch of shortcuts that just install extra applications. For instance, there are launchers which will download additional pieces of the LibreOffice suite, the GNU Image Manipulation Program, and the Chromium web browser, among others. These one-off launchers can be useful shortcuts, I suppose, though they seem like an awkward alternative to a software manager.
Software management
Speaking of managing software, Bunsen ships with the Synaptic package manager. This classic package manager helps us download, remove, and upgrade packages. It can also enable remote repositories and filter search results. Synaptic is quite powerful and works quickly. It is not particularly streamlined or modern, but it gets the job done. For those of us who like working from the command line, Bunsen provides the APT command line tools.
Conclusions
After playing with BunsenLabs a bit I arrived at a couple of thoughts. The first is that the distribution generally does what it sets out to do. It's basically Debian with the Openbox interface and some nice customization scripts. As far as missions go, it may not be particularly glorious, but I always like it when a distribution does what it advertises, whether its goals are big or small. Bunsen is probably ideally suited for low-resource environments, particularly where CD install media or 32-bit processors are being used.
While Bunsen does accomplish its goals, I am not certain that I can pinpoint a good audience for the distribution. As I mentioned above, Bunsen probably most appeals to low-resource environments or people running older hardware. However, the same could be said of Debian, or other low-resource derivatives. I'm not sure if there is anything specific to BunsenLabs which really sets it apart.
Don't get me wrong, I like Bunsen's welcome script and I like Openbox, and I like the stable Debian base. However, there are other distributions, even other Debian-based distributions, which use about the same amount of resources and have more modern or more beginner friendly interfaces. Just about any Debian-based project with, for example, the LXDE or Xfce desktops will use about the same amount of RAM, CPU, and disk space while offering a less cluttered menu and more friendly configuration tools.
I'm not suggesting Bunsen is bad - it's doesn't really do poorly at anything it sets out to do. However, I do think there are other distributions which accomplish similar goals with friendlier interfaces. So what I'm suggesting is that Bunsen probably really appeals, almost exclusively, to people who like minimal window managers and who like Debian. It can be useful in other situations, but this seems to be the project's niche.
* * * * *
Hardware used in this review
My physical test equipment for this review was a desktop HP Pavilon p6 Series with the following specifications:
- Processor: Dual-core 2.8GHz AMD A4-3420 APU
- Storage: 500GB Hitachi hard drive
- Memory: 6GB of RAM
- Networking: Realtek RTL8111 wired network card, Ralink RT5390R PCIe Wireless card
- Display: AMD Radeon HD 6410D video card
* * * * *
Visitor supplied rating
BunsenLabs Linux has a visitor supplied average rating of: 8.4/10 from 36 review(s).
Have you used BunsenLabs Linux? You can leave your own review of the project on our ratings page.
|
| Miscellaneous News (by Jesse Smith) |
Fedora plans to make Btrfs the default filesystem, FreeBSD imports new OpenZFS code, DragonFly BSD publishes documentation in ePUB format, openSUSE presents Jump edition
The Fedora distribution is planning to switch the default filesystem used in its desktop editions, migrating from ext4 to Btrfs. The change is currently planned for Fedora 33, which is scheduled to be released in October 2020. "User data is the most important thing on a computer. Whether it's source code for the next big release, family pictures, a music library, or anything else, you want it to be safe. Changing the default file system is not a change to make casually. The Fedora Project is changing the default file system for desktop variants (Fedora Workstation, Fedora KDE, etc), for the first time since Fedora 11. Btrfs will replace ext4 as the default filesystem in Fedora 33." The move comes about two years after Fedora's sponsor, Red Hat, dropped support for Btrfs.
* * * * *
In the recent past the reference implementation for the ZFS advanced filesystem shifted from Illumos to the Linux on ZFS project. More active work was happening in the Linux branch of ZFS and developers have largely agreed to shift focus to using the Linux on ZFS code as the common upstream base. The FreeBSD team is in the process of migrating from their previous implementation to the new OpenZFS code. "Work on merging FreeBSD support in to what was at the time ZFS on Linux began in August 2018. I first publicly proposed transitioning FreeBSD to (new) OpenZFS on December 18th, 2018. FreeBSD support in OpenZFS was finally completed in December 2019. A CFT for downstreaming OpenZFS support in to FreeBSD was first issued on July 8th. All issues that were reported have been addressed or, for a couple of less critical matters there are pull requests in progress with OpenZFS. iXsystems has tested and dogfooded extensively internally. The TrueNAS 12 release is based on OpenZFS with some additional features that have not yet made it upstream." Further information can be found in the change's log message.
* * * * *
The DragonFly BSD project has a Handbook which provides useful information on the use and care of DragonFly BSD systems. Vincent Defert has converted the existing documentation, along with various helpful tips, into ePUB format. The two documents in ePUB format have been posted on-line for the community to read.
* * * * *
The openSUSE team has published new alpha builds of the distribution's Jump edition. Jump is an effort to bring the SUSE Linux Enterprise (SLE) and openSUSE code bases and packages closer together. "The prototype project openSUSE Jump is now available for Alpha phase testing. Jump is an interim name given to the experimental distribution in the Open Build Service as developers have been trying to synchronize SUSE Linux Enterprise binaries for openSUSE Leap. The efforts are trying to bring the codes of Leap and SLE closer together, which was previously mentioned in an article titled New Prototype Builds Bringing Leap, SLE Closer Will be Available Soon." The new Jump builds for supported architectures are now available for download.
* * * * *
These and other news stories can be found on our Headlines page.
|
| Questions and Answers (by Oded Arbel) |
More information about dynamic versus static linking
Regarding the ongoing discussion on the pros and cons of operating systems using dynamic linking of application provided vs static linking - Jesse Smith in the DistroWatch Q&A addressed most of the concerns I had with the original article, by Drew DeVault, that sparked this discussion, but I think the question of the disk space still needs to be addressed more fully. So:
Wouldn't statically linked executables be huge?
Not necessarily so - would they be larger? Sure - the original article does some hand-waving about how many dynamically loaded symbols are directly referenced by a linking executable and concludes that as on average applications directly reference only 4.6% of symbols exported from the libraries they consume, and modern compilers are good at eliminating code that isn't used, the size difference can't be that significant.
So lets look at an example: the cURL program is available on many operating system as it is useful tool to interact with the Internet. It is a good example, in my opinion, as while it has a rather simple facade, it has a lot of internal complexity as it attempts to handle anything the Internet might throw at you (and not only with HTTP, it supports FTP, IMAP, SMB and more). It also uses a fair amount of features from external libraries from OpenSSL to SQLite.
Drew's symbol analysis code from the above referenced article reports /usr/bin/curl on Ubuntu 20.04 to be using 6.8% of the symbols exported by the dynamic libraries it is linking with, so it is still in the ballpark of what you'd expect if you'd read Drew's article.
The problem with that analysis is that it assumes that counting the number of directly referenced symbols maps well to the additional code size that will be required in the application if we bundle the libraries into the executable: 6.8% use translates to 6.8% (of the size of all libraries) executable size increase. But this is very likely not true! The reason libraries are even a good idea, in and of itself (regardless of the discussion of dynamic vs. static linking) is that they hide a lot of complexity behind a small API. Usually libraries handle all that internal complexity by being made out of a lot of small pieces that call each other to implement complex logic. My application may only call into a library in a couple of places, but those functions will call other functions inside that library (and in other libraries) to do what I want them to do.
How can we even measure that? We'd need to build a tool that traces not only which exported symbols my application uses, but also what symbols those symbols use, and what those other symbols use, and so on and so forth - recursively to each leaf of the tree. Fortunately - such a tool already exists! We call this tool "a compiler". As asserted in Drew DeVault's article, a modern compiler walks through the tree of symbols an application uses and only includes what code it needs to make sure everything needed is available, trimming out everything else. So lets just get down to it - if we compile cURL statically, how large would it be? Because cURL uses quite a few libraries (45 on Ubuntu 20.04) and each and every one of them has to be built statically to be able to build cURL statically, and I'm pretty lazy, I would answer that by looking at Stali Linux - a completely statically linked Linux operating system, whose completely built "root filesystem" can be downloaded or browsed from their GitLab repository. By the way, the Stali FAQ spends quite a bit discussing the space efficiency of static linked executables, including memory consumption - which is a whole new can of worms that I will not be getting into here, but is worth exploring when considering a modern workstation operating system.
On Stali Linux, the cURL executable is 2.8MiB in size - that is quite a bit more than the same executable on Ubuntu 20.04, where it is only 236KiB in size. This is of course not the whole story as in Ubuntu 20.04 cURL requires an additional 45 dynamically loaded libraries weighting in at a total of 19.8MiB [1]. Assuming that cURL under Stali uses has the same set of features (which it doesn't - mostly because Stali hasn't seen an update in over 3 years and its current version is using the - even older - version 7.48 of curl, but it also doesn't use a lot of features you do get on Ubuntu such as support for IDN, HTTP2, SSH, Kerberos and others). I'm going to ignore that for now (but we'll get back to it much later) and just conclude that Stali's cURL executable is 14% more space efficient than Ubuntu installation. That is more than twice what you'd expect from the symbol analysis! The actual figure, excluding all the libraries that the Ubuntu's cURL uses and Stali's doesn't is actually 21%.
This shows that the analysis of directly referenced symbols does not provide a good estimate of the size efficiency of statically executed binaries as to make the application work, the compiler has to grab a lot more than just those directly referenced symbols from the application.
So to summarize:
- Question: Wouldn't statically linked executables be huge?
- Answer: Yes, they would - often ten times larger or much more. They will still be smaller than the sum size of a dynamically linked executable and its libraries - but not by as much as you'd expect - maybe a fifth.
But, you might be asking, wouldn't that still make it a net benefit to have the entire operating system statically linked? I would like to save 80% on my disk space bill.
Well, the thing is - as we've just shown - most of the bulk of a dynamically linked executable is in the libraries, the executable itself is just a tiny part of the code size of a dynamically linked executable. While cURL is 236KiB, Firefox - if we take another example - which does almost everything that cURL does and oh so mmmuuuccchhh more has an executable that is 688Kib on Ubuntu 20.04 - just 450 more KiB for a massive graphical interface, virtual machines, databases, sandboxing, etc. It is all in the dynamically linked libraries - which are shareable! And re-use of dynamic libraries actually pays back very well. cURL is actually a good example of such re-use: most of the cURL logic is in its shared library - libcurl - and there are quite a few application that use it to support cURL-like features for getting and pulling stuff off of servers with all the weird and exciting complexity of the Internet. Looking at my system, I can see [2] that libcurl is used by 22 OS-provided applications, other than cURL itself - which puts it in the top 20% of most used dynamic libraries on my system. Using the above 21% as a guideline, having a library used by five executables will a net disk size reduction compared to statically linking, and libcurl definitely passes that threshold - so building and using cURL dynamically saves a lot of disk space.
But how does this apply to the entire operating system? According to Drew DeVault, "Over half of your libraries are used by fewer than 0.1% of your executables" - so do benefits like we get from cURL apply system wide? Taking the 21% "less space than statically linking" for building cURL statically I wanted to see what might happen if all OS provided executables were delivered as statically linked executables and all the dynamic libraries removed - would we gain or lose space and how much?
The results on my system [3] are that dynamic libraries being used by executables weight in at 1.43GiB, while the suspected estimated to apply 21% of that cost to each using executable would be 7.29GiB. So re-use of dynamic libraries serves about five times reduction in disk space!
As we discussed Stali Linux before, as an example of a completely statically linked operating system, then another way to look at the same question is to just do a straight up comparison of how much does a Stali Linux installation takes vs. an installation of a dynamically linked operating system, like Ubuntu. It is not really an apples to apples comparison as Stali is much more minimal than most operating systems. Still, it is worth noting that:
- Stali's rootfs bin directory has 212 files weighing 50.2MiB for an average of 242KiB per application.
- The buntu:20.04 docker image (which is supposedly similarly minimal to a Stali installation) has 385 executables in its OS application directories [4] with 68.2MiB between bin, sbin and the library directories (that contain things other than dynamic libraries, but I decided not to bother with filtering those out) for an average of 171KiB per application.
This is not as pronounced a difference, but still clearly shows that dynamic linking is a considerable net disk space positive - 30% saving in the above test, not taking into account that amount of extra functionality that a minimal Ubuntu provides over Stali.
P.S. Yet another point for dynamic linking
Something else worth noting about the advantage of dynamic linking: it is much better for downstream developers. If I'm developing an application that uses libcurl on Ubuntu, the development package includes just the things that I need: some header files and a tiny static library that just causes the compiler to link with the dynamic libcurl library. After building I know for a fact that whatever I do with libcurl I'll get identical results to running cURL on the command line, making it easier to debug problems with my code (if the behavior is different compared to the cURL command line, then my code is doing something incorrectly). On Stali Linux there are no development packages, but if I imagine that there are, it would likely be a complete source dump of the curl repo (which it kind of is) where I would first need to build the library locally and when my application behaves differently than the cURL command line - who knows why? it could be because I'm doing something wrong, or because my build process is somewhat different than Stali's, or because we are not using the same version - it is impossible to tell without a lot more additional testing.
* * * * *
Scripts
1) ldd $(which curl) | perl -nle 'm,=> (/\S+), and push @libs,$1; END{ foreach $lib (@libs) { @st=stat $lib; $sum+=$st[7]; } print $sum/1024/1024;}'
2) find /usr/bin -type f -executable | while read file; do ldd "$file" 2>/dev/null | grep -q libcurl && echo $file; done | wc -l
3) find /usr/bin -type f -executable | xargs ldd 2>/dev/null | perl -nle 'm,=> (/\S+), and $libs{$1}++; END{ foreach my $lib(keys %libs){ @s=stat $lib; $actual+=$s[7]; $cost+=($s[7]*0.21*$libs{$lib}); } print "Actual total size: $actual"; print "Expected total cost: $cost";}'
4) for dir in /usr/bin /usr/sbin; do find $dir -type f -executable; done | wc -l; du -ks /usr/bin /usr/sbin /usr/lib* | perl -nle 'm/^(\d+)/ and $sum+=$1; END { print $sum/1024; }'
License
Licensed under CC0 license: To the extent possible under law, I hereby waive all copyright and related or neighboring rights to this article.
* * * * *
Additional answers can be found in our Questions and Answers archive.
|
| Released Last Week |
Tails 4.10
Tails (The Amnesic Incognito Live System) is a Debian-based live DVD/USB with the goal of providing complete Internet anonymity for the user. The product ships with several Internet applications, including web browser, IRC client, mail client and instant messenger, all pre-configured with security in mind and with all traffic anonymised. The project's latest release, Tails 4.10, fixes support for Atheros USB wi-fi devices and USB tethering from iPhones. There have also been a number of package updates, including the kernel, which improves hardware coverage. The release announcement reports: "Changes and updates: Update Tor Browser to 9.5.4. Update Tor to 0.4.3.6. Update Electrum from 3.3.8 to 4.0.2. Update Linux to 5.7.10. This should improve the support for newer hardware (graphics, wi-fi, etc.). Hide the welcome message when starting Thunderbird. Fixed problems: Fix support for USB wi-fi adapters with Atheros AR9271 hardware. Fix USB tethering from iPhone. For more details, read our changelog."
Parted Magic 2020_08_23
Parted Magic is a small live CD/USB/PXE with its elemental purpose being to partition hard drives. The project has published an update which begins the distribution's migration to phase out 32-bit editions. "This version has some major changes that might be a big deal to some people, but I don't think it will be a problem for most users. I was forced to drop the 32-bit kernel after finding out syslinux has an initramfs size limitation. I will include an old version with a 32-bit kernel. You can download it from your file list. 32-bit was going to be dropped in the near future anyway. 32 and 64 was dropped from the boot menus. If you have a custom boot menu or PXE configuration, please make a note of this change. For example, m64.img was renamed to m.img. Parted Magic no longer uses Aufs. The conversion to Overlayfs was nearly 100% done by D.L.C. Burggraaff. This means kernel updates will no longer be delayed waiting for an Aufs patch." further information, including a list of updated packages, can be found on the distribution's news 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,117
- Total data uploaded: 33.5TB
|
| Upcoming Releases and Announcements |
|
Summary of expected upcoming releases
|
| Opinion Poll (by Jesse Smith) |
Fedora adopting Btrfs as the default filesystem
One of our news stories this week was about the Fedora distribution switching its default filesystem from ext4 to Btrfs on Workstation spins. Btrfs offers a lot of extra features, including built-in multi-volume support, compression, and snapshots. What do you think of this move, are you excited to run Btrfs on Fedora?
You can see the results of our previous poll on running commercial or community projects in last week's edition. All previous poll results can be found in our poll archives.
|
Running Fedora on Btrfs
| I plan to run Fedora on Btrfs: | 165 (11%) |
| I do not plan to use Fedora on Btrfs: | 128 (9%) |
| Have not decided yet: | 99 (7%) |
| I am not a Fedora user: | 1045 (73%) |
|
|
| Website News |
DistroWatch database summary
* * * * *
This concludes this week's issue of DistroWatch Weekly. The next instalment will be published on Monday, 7 September 2020. 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) |
|
|
|
 bc1qxes3k2wq3uqzr074tkwwjmwfe63z70gwzfu4lx  lnurl1dp68gurn8ghj7ampd3kx2ar0veekzar0wd5xjtnrdakj7tnhv4kxctttdehhwm30d3h82unvwqhhxarpw3jkc7tzw4ex6cfexyfua2nr  86fA3qPTeQtNb2k1vLwEQaAp3XxkvvvXt69gSG5LGunXXikK9koPWZaRQgfFPBPWhMgXjPjccy9LA9xRFchPWQAnPvxh5Le paypal.me/distrowatchweekly • patreon.com/distrowatch |
|
| Extended Lifecycle Support by TuxCare |
|
|
| Reader Comments • Jump to last comment |
1 • Bunsen (by Vern on 2020-08-31 01:09:19 GMT from United States)
I really enjoyed my time with Bunsenlabs. It was a very minimalist. But could easily add to its features.
I guess I just got lazy, and installed Ubuntu. I've been meaning to put Bunsen on another partition, just haven't gotten around to it.
2 • Fedora (by Andy Prough on 2020-08-31 01:23:35 GMT from United States)
I did a 1-semester class on python one year using Fedora. The gnome extensions I used to make it halfway usable got broken by updates during the semester. Package management with dnf or yum or whatever they were using then was slow and laborious. Haven't tried it since. It's probably fine now, but it doesn't offer anything I can't get just as easily with a Debian based or Arch based system. I've used btrfs a lot with opensuse Tumbleweed and I enjoyed it, but I'm sure I won't try it with Fedora. With all the cheap cloud storage and external storage available these days, I value file system speed and stability far more than any snapshot ability.
3 • BTRFS can be good news. (by Greg Zeng on 2020-08-31 01:28:09 GMT from Australia)
> "The move comes about two years after Fedora's sponsor, Red Hat, dropped support for Btrfs."
Practically all Linux & Windows operating systems can read-write BTRFS partitions. Most (all?) Linux systems can use BTRFS partitions, but some Linux utilities have trouble with recognizing BTRFS partitions; Grub Customizer type programs included.
Windows needs the freeware driver: "Winbtrfs V1.7.3". Similarly, most can read-write Microsoft's NTFS-compressed partitions. Now that Microsoft is a paid up sponsor of both The Linux Foundation, Open Source Security Foundation, and the Open Invention Network, Microsoft's NTFS is now open to Linux. Paragon's & the 3G NTFS systems are now distant history.
Both the open source (Microsoft) NTFS & BTRFS share many features: encryption, compression, meta-data journaling, etc. However BTRFS has so many other features, that it is much slower in its use than other partition systems, as tested by independent specialists.
Personally my BTRFS partitions create so much trouble with the many versions of Grub Customizer. Both BTRFS & NTFS need specialized programs to repair, defragment and maintain their respective partition systems. In this need, they are similar to EXT4, ZFS & other partition systems.
BTRFS seems to net have many business friends yet. Reports of unreliability seem common.
4 • Of btrfs and EXT4 (by tom joad on 2020-08-31 02:43:20 GMT from Austria)
A few months back I got the crazy idea to give ZFS a spin. Bad deal. Ooogly deal actually as it caused me many headaches. Many moons back I was hot to use MX linux which at the time was btrfs. That caused me to ditch that, though I really like MX linux, and run to 'steady Eddie' Mint Cinnamon using good Ol' EXT4. I gotta get stuff done and by stuff I don't mean daily troubleshooting this or that.
As a farmer once told me, "If it ain't broke, don't fix it."
Lastly, Fedora moving from EXT$ to btrfs....yawn. Ain't no way I am ever going over there!
5 • BunsenLabs (by OneHu on 2020-08-31 03:02:43 GMT from Mali)
BunsenLabs has a place. It fills a void. LXDE seems inactive, LXQt is not yet polished, XFCE has ugly windows round corners (among other things). There is no choice on Debian other than #!++ or BL. I wish them a long life.
6 • @4 - MX and btrfs (by Hoos on 2020-08-31 03:17:28 GMT from Singapore)
"...Many moons back I was hot to use MX linux which at the time was btrfs. That caused me to ditch that, though I really like MX linux, and run to 'steady Eddie' Mint Cinnamon using good Ol' EXT4....."
MX has always had ext4 as the default file system.
7 • Target group for bunsenlabs (by Hoos on 2020-08-31 03:28:12 GMT from Singapore)
Many users, including me, remember crunchbang fondly. I think that bunsenlabs can essentially be considered the CB community's successor distro, although I believe that in the immediate wake of crunchbang's demise there were a few other distros seeking to revive that crunchbang look and feel.
I think that openbox Debian fans loving a certain minimalist aesthetic and the ability to tweak their desktop would enjoy bunsenlabs.
8 • Btrfs (by corcaigh on 2020-08-31 03:56:58 GMT from United States)
I have not tried Btrfs outside of Virtualbox, mostly because of not needed for my system. I have been using ext4 for my system files since its acceptance as default in Ubuntu and derivatives; xfs is used on several external HDD units, where my media and personal files are stored. I'm using Backintime for backups. This seems to work for my purposes. ZFS is a possibility, someday...
9 • Bunsenlabs (by Pete on 2020-08-31 07:42:18 GMT from United Kingdom)
Wow! Whatever happened to openbox being lightweight ? 375Mb of RAM ! My Lxqt uses less than 280 on my config of Lubuntu 20.04.
10 • filesystem for media/data storage (by usman on 2020-08-31 07:56:54 GMT from Indonesia)
Even after read the reasons, overhead and reserved space of ext4 seems too much. The overhead stuff too complicated to tweak for ordinary user like me. In my opinion too much space wasted especially my external HDD only for media & data storage.
Considered to change my storage filesystem. But reading the review above about another filesystems, seems ext4 the most stable right now. Maybe xfs worth a try, as my use case similiar to corcaigh@8.
Thanks everyone for sharing experience using another filesystem.
11 • BTRFS (by Ano69 on 2020-08-31 08:17:15 GMT from Bulgaria)
It would be nice to include in the poll the option "I will use/I use BTRFS, but not on Fedora". This is my case - I have 5 BTFS filesystems with the combined size of 60 TB, RAID6 profile.
It's OK filesystem, but I will probably move to my own (under active development) which combines in one all of the features available in different filesystems, but not on one place.
12 • BunsenLabs & choice on Debian (by kernelpanic on 2020-08-31 08:36:54 GMT from Germany)
@5 OneHu
"There is no choice on Debian other than #!++ or BL"
what a statement! because window corners are not rounded there but edgy? ;-)
Just in case you are really interested what a lean and mean debian based distro can do,
I strongly recommend you take a look on antiX!
13 • BL and Debian choices; leanness (by Hoos on 2020-08-31 09:05:42 GMT from Singapore)
Is low resource consumption the only reason for using BL?
I really don't think so, to be honest. I think the coolness of the original crunchbang black/grey and white aesthetic really did capture people's imagination, inspiring a whole lot of other distros, not just BL and crunchbang++ but also archbang and whatever other [???]bangs there are.
I never got into any of the CB successors, but I can see why people would use BL or crunchbang++.
antiX comes with quite a few window managers by default, but openbox is not one of them.
14 • Bunsenlabs (by OstroL on 2020-08-31 10:34:58 GMT from Poland)
"While Bunsen does accomplish its goals, I am not certain that I can pinpoint a good audience for the distribution." Jesse's review
Well, once #! had an audience. If it lived today, it might still have a large following. :) By the way, didn't notice the word Crunchbang in the review.
It was supposed to live through Bunsenlabs, and while the majority of the scripts are the same, Bunsenlabs doesn't live up to #! Crunchbang. There's still one distro that keeps the #! flag flying -- Crunchbang++. Maybe, Jesse should review it alongside. https://crunchbangplusplus.org
There's also Monara Linux (Google it), which was based on Debian 8.5, but can be upgraded to Debian 10.
15 • BTRFS (by jan on 2020-08-31 10:51:21 GMT from Poland)
As a home Linux user, I remember the days same 15 years ago when every couple of weeks I would hop from the then latest Mandrake version to Suse, and then repeat it the other way around. With time, I had to abandon Suse, as with every installation of a new version it was getting more and more difficult to resolve the dependency hell created by a lack of automated dependency resolution, as adopted by other distros. And then comes a miracle -BTRFS- that let's us restore the system to previous, healthy state (in theory). To me it seems like a workaround and not a real solution. I would say that without BTRFS openSuse would be an unusable distro. Waiting for Suse to clean up its act, because it is a very good distro (in theory). As with everything computers, the usecase decides what is most convenient. I'm sure BTRFS is a blessing for some - surely not for me.
16 • Xfce round corners??? (by Bob on 2020-08-31 11:27:15 GMT from United States)
@5 I have seven systems with Xubuntu. Two 16.04, four 18.04, and one 20.04, and y'know, there isn't a single "round corner" to be found. You must have overlooked the "Window Manager" feature provided with every release xfce. Cheers.
17 • openSUSE unusable? (by Igor on 2020-08-31 13:22:57 GMT from Croatia)
@15 Umm, then I must be kind of mistake, as I am using it happily since 12.3 (in practice). I have used Btrfs' recovery function three to four times, and only once (kernel update) was it not because of my own fault. So how about trying it out instead of speculating about it?
When listening to people talking out their prejudices, usually about people from other countries, I always ask: "how many of them did you meet for any longer than 15 minutes?" I have noticed that many commenters here state something like "no way this is ever going to land on my machine", without having any actual experience with the thing (not only Btrfs), relying instead on various forums with the like contributors. What does such a comment actually communicate? Ill will. Who benefits from this?
18 • 0penSUSE (by Friar Tux on 2020-08-31 15:33:26 GMT from Canada)
@17 (Igor) I've tried OpenSUSE, and for more than 15 minutes at a time, and, unfortunately, I have to agree with @15. BTRFS and SUSE (or any of its derivatives) don't go on my laptop. For the same reasons @15 mentions. My present distro lets my get my work done without have to constantly fiddle with the OS to keep IT working (which was required in both SUSE, and its derivatives, and most of the BTRFS distros I've tried).
EXT4, for me, is stable and the easiest to work with. In today's OS environment backing up and restoring bricked computers is so quick and easy on ext4, there's not real reason to switch to any other system. (And, like you, most of my having to restore anything is due to MY screwing up.) So, to be sure, some of us actually DO know what we're talking about and not just making arbitrary comments.
19 • @17 Igor: (by dragonmouth on 2020-08-31 16:19:39 GMT from United States)
I've been around long enough and have tried enough distros to know what I will and will not like. I don't have to try banging my head on the wall to know it is going to hurt and give me a headache. BTRFS is going to give me a headache. Like FriarTux I'll stick with what I know and keep using ext4.
20 • CrunchBang++ (by Keith on 2020-08-31 16:53:16 GMT from United States)
@14 "There's still one distro that keeps the #! flag flying -- Crunchbang++."
WOW! Thanks for that link, OstroL. I just installed it. This is IDENTICAL to what I remember back in the corenominal days. I'm getting favorable flashbacks to the good old #! way of Linux Life. It's PERFECT! It's a keeper.
-I've got a fridge full of NOS and Monster energy drinks...it's going to be an all-nighter! :)
21 • Ext4 and Btrfs have different use cases (by Beep on 2020-08-31 18:32:59 GMT from United Kingdom)
I'm very happy Fedora will make Btrfs the default file system. Theodore Ts'o (one of the main Ext4 developers) said years ago that - long term - there is a need for a more advanced Linux file system that supports things like snapshots, and that Btrfs is our best bet. He also predicted that it would take a long time for Btrfs to mature. I see Fedora's move as an endorsement of Btrfs and I'm hopeful this will be good for both Fedora and Btrfs.
There's an interesting interview with Ts'o at https://pdfs.semanticscholar.org/3e03/96de4a02d47d4dc1fe3273507fc0d997ffea.pdf
22 • OpenSuse&Btrfs (by @15 John on 2020-08-31 18:36:55 GMT from Switzerland)
OpenSuse user here. Sorry to disappoint you, but OpenSuse is a perfectly usable distro, with or without Btrfs. Maybe you should try it (after 15 years) before writing funny things about it.
23 • Well done, MX Linux 19.2 KDE (by Brian Masinick on 2020-08-31 21:05:16 GMT from United States)
I tried out MX Linux 19.2 KDE, and I now have it on one of several partitions on my Dell Latitude 5558 laptop. Debian-based distributions dominate this multi-boot setup, including the Xfce and KDE variations of MX Linux, the base and 'runit' variations of another "family member", antiX, plus a Sid implementation of Debian Buster/Sid 10.5 (that one was an "accident", I added a repo to pick up one package, not carefully examining it, only to discover that it turned on the "Sid" bits! No biggie, I love Sid and I've used it for years, and the boo-boo didn't mess up my Debian system. But the main focus of my comment here is to commend and complement all of the antiX and MX Linux developers. As solid and useful as the Debian distribution is, the Debian team tends to leave tools, appearance and customization features up to the community, and quite a few distributions that are based on Debian do very well with it. I find, nevertheless, after two decades of using Debian software, that the antiX projects that produce the antiX and MX Linux distributions do the best job of adding significant value. MX Linux creates a series of very usable, high quality distributions that well on systems ranging from new to around five-six years old (though some may be able to use it for much longer). The antiX project is specifically targeted to systems that even MX Linux may struggle to support. Though it usually works GREAT with newer systems, antiX can generally work with ten year old hardware and even works on quite a few old 32-bit systems, something that few OS, free or commercial, can do anymore.
Huge kudos to the antiX and MX Linux teams! The MX Linux KDE release is yet another high quality effort that this small, highly skilled team has expertly engineered and tuned for their users who enjoy using KDE.
24 • @Pete re:BL RAM (by hhh on 2020-08-31 21:35:16 GMT from United States)
You can easily get BL down to 280MB, start by removing some of the panel applets. Cinnamon and Plasma run at 600+MB OOTB, what's your point? RAM is there for a reason, namely to be used.
25 • antiX 19.2 (by dragonmouth on 2020-08-31 21:53:33 GMT from United States)
I wanted to resuscitate a Dell Dimension 8250 I have taking up floor space. I used Slacko 6.3.2, Bionic Pup 8.0.23 and antix 19.2. I never finished the Slacko install as, at one point, I could not figure out what to do next. The install of Bionic Pup went smoothly but I ran into problem once I got the distro going. I suppose I should have read the manual for Slacko and the Pup but I figured since they are aimed at newbies, I didn't have to. Wrong! Then I tried the antiX. The difference with the other two was night and day. The antiX install is self-documented. Every entry that can be made is clearly explained. Whereas Slacko and Bionic Pup require some Linux knowledge, antiX can be easily installed by a complete noob. IMNSHO, antiX is the easiest to install of all distros, including the *buntus.
Congratulations to anticapitalista and his gang!
26 • BTRFS Can Be Excellent (by M.Z. on 2020-08-31 22:24:05 GMT from United States)
Like some others I've actually run BTRFS on a regular desktop system. It was an option to install Mint's LMDE 3 version via Calamares with BTRFS so that Back in Time would be able to create snapshots & restore easily. I had virtually zero issues with it, as in I neither had problems with BTRFS, nor did I need to go back to a snapshot due to Mint Debian being so stable. There was however a high degree of satisfaction it gave me just from looking at all the daily & weekly snapshots that were available on the root partition just in case.
Sadly I had a fair amount of issues with trying to get it to work in LMDE 4 & getting Grub customizer in Mageia 7 to see & boot the thing. Running all my LMDEs on Ext 4 now, but BTRFS is the main thing I miss from LMDE 3, and mostly just for the feeling of the cutting edge safety net that is so much faster & easier than rsync.
27 • can't you see, it's not at all about Btrfs or openSUSE (by Igor on 2020-09-01 09:44:36 GMT from Croatia)
@19, so how do you explain the fact that John, M.Z and me all (actually, not hypothetically) banged our heads against the wall with no unpleasant consequences? Is it just because God is taking special care about fools?
@ both, 18 and 19, to start with I am not arguing against Ext4, I am actually using it on my laptop, and it is OK. You may have noticed that quite a few times Jesse concluded his reviews with the statement like "distro xyz didn't work FOR ME", only to read in comments that it worked for someone else. Also, when you take a look at Distrowatch readers' ratings of any distro that collected more than hundred reviews, you are going to meet all the available ratings from 1 to 10. What does it tell you?
There are three hardware-software scenarios in the personal computing world we discuss here. All the hardware is projected to work with dominant operating system and tested against it because this is a sure bet (no, not just Windows, but Android as well). Or, a manufacturer produces both of it, so that their OS works only on their devices, and the rest of the software must be programmed accordingly to make everything work reliably. Or, brilliant guys find the way to free up almost any hardware by means of ingeniously programmed software. Only, in this case the outcome is not as predictable as the former two are. The situation is mitigated by the diversity of distros, so if some one is not working FOR ME (i.e. my particular machine), the other one is going to work. Also, if it is not working for me, it will work for someone else.
Finally, let me put my argument once again. Sweeping derogatory comments are not in tune with the collaborative nature of the free and open software. Brilliant (and maybe some less brilliant) tech guys are giving some of their work to us, to see if we can make use of it. They do not deserve to be rebuked for doing so.
Users are supposed to contribute their experiences that can help the others, not verbal tribal wars of ext4 against Btrfs, sysV init against systemd, or our good distro against the wicked monetizing one. Else we might end up like european football hooligans arranging physical fights someplace police is not going to disturb us.
28 • Has Btrfs interest waned since OpenZFS became a thing? (by Any name would smell as sweet on 2020-09-01 10:41:57 GMT from United States)
Serious questions:
With the existence of OpenZFS i.e. ZFS on Linux in today's era, is there as much of a demand for Btrfs? If Fedora was going to change to something more hip than ext4, what objective reasons would they have for Btrfs over OpenZFS?
(Serious questions. I haven't looked at filesystems since ReiserFS (3) vs ext3 was a point of conversation. I'm still running ReiserFS on my daily driver Slackware-basted distro. EXT4 for other partitions e.g. Ubuntu 20.04. JFS for storage.)
29 • Hooligans (by Otis on 2020-09-01 12:19:57 GMT from United States)
@19, yeah, those who get mad or frustrated with a distro and express their angst herein, mentioning the problems and the devs etc, are analgeous to street hooligans.
We enter the relationship with a distro usually with an iso and a lot of hope. Often, when those hopes don't pan out we feel badly directly proportionate to how much time and effort we've put into trying to make it right.
And we get to vent here there and everywhere. It's okay.
30 • BTFRS @27 (by Jan on 2020-09-01 12:58:11 GMT from Poland)
Igor - I do respect all people commenting here and their views. You are 100% correct that Suse works for you perfectly well - but I guess you are a professional programmer and an IT professional. I am only an amateur, never wrote code (only copy/paste from on-line tutorials). What I often do is installing, trying out, often uninstalling, new applications, experimenting. This has always ruined Suse, however MX Linux and Xubuntu proved to be rock solid despite heavy onslaught of new and alien stuff.
I tried open Suse (both Leap and Tumbleweed) as well as Gecko Linux just last year.
I want to stress that I respect all Suse developers and those who make Suse tick. But like many things foss and open source, what right do we have to demand and criticize, if we don't contribute or pay? But still, this is a place for sharing opinions, if they be of any value or inspire someone. So I expressed my opinion on Suse, because it does not work for me nowadays, and it makes me real sad, because I remember it used to be different before.
31 • @24, BL, RAM (by WhatMeWorry on 2020-09-01 12:59:12 GMT from United States)
"You can easily get BL down to 280MB, start by removing some of the panel applets. Cinnamon and Plasma run at 600+MB OOTB, what's your point? RAM is there for a reason, namely to be used."
Sure. I have 8 and 16 GB of RAM on my PCs, and plenty of storage. But if RAM or storage footprint don't matter, then the term "lightweight" has no meaning. So why advertise it as such? If anyone enjoy the distro, I'm glad for them, but when you start removing applets to bring down RAM, what's the point?
Porteus idles at 340 MB with Plasma and 220 MB with XFCE. Redcore Plasma idles about 360. Porteus ISO is a fat 3.3 GB while Porteus is under 400 MB. Are they both lightweight, or only Porteus?
Star, based on Devuan, idles at 130 MB with Openbox and at 230 with XFCE. If I'm going to call anything "lightweight" that would be it, if it matters.
32 • @28 JFS (by curious on 2020-09-01 13:07:29 GMT from Germany)
Kudos for mentioning JFS. Its a very stable, reliable filesystem that gets too little publicity. Its a bit like XFS, but without the specialization for very big files.
JFS is in fact so stable and bug-free that Debian considered dropping support for it because there was supposedly no maintenance activity (meaning there were no bugs to be fixed)...
33 • OpenSuse and BTRFS (by anon on 2020-09-02 00:19:45 GMT from United States)
I've used OpenSUSE on many systems and I never ran into any issues, so I find it strange that others have such a bad impression of it. It was just as stable as Debian, if not more so. I used YAST during the install and it fetched and installed everything that I needed with no issues. All codecs were present, all media programs worked perfectly, and wi-fi was fast and reliable. I've encountered far more problems with the more popular distros.
I support BTRFS despite its flaws. I love the idea of a home grown linux solution, and I hope that more distros support it and contribute to it. I'd rather see Linux build its own high level file system with snapshot capability and a Linux-friendly license instead of trying to import ZFS into the ecosystem.
34 • Freedom (by Igor on 2020-09-02 09:32:59 GMT from Croatia)
@Otis: Sure, I have spent hours and hours trying to install distros on various machines and make them work, sometimes unsuccessfully, just like you. And I was swearing and cursing all along (believe me, croatian language is extremely creative in this particular respect), when things didn't work. But I wouldn't go public with it.
Rude as it is, I did not compare this behaviour to hooligans, but lighting up the flames of us against them, this or that technology that is wicked and should be rooted out of our movement. Though such a comment can be written in polished words, it is unnecessarily divisive.
In free world there is place for almost everything and everyone. In hooligans' world there is us or them. As the saying goes, it is warm in the herd and it stinks.
We all experienced occasional disappointments with FOSS, any FOSS, but this is the price of freedom. Freedom, by its nature, is seldom coupled with convenience. Every here or there I read complaints about low market share (market? Isn't it a place where people sell and buy?) of desktop Linux. It is a bit below 1% and this compares well to general appreciation of freedom versus convenience.
@Jan: It is perfectly OK to go with the software that works for you, and contribute there. You don't have to code. There are many other ways to say thank you, money being pretty close to the end of the list, though not at the very end (and tending to move forward). If the things don't go as expected, and you want to do something about it, note the error messages. Take a look at system logs looking for words like "error", "warning", "alert". Focus to the time when you experienced the problem. This is easy to learn. Sure, you don't understand this arcane techobabble, me neither. Even Jesse, and he is a pro, often can not figure out why things don't work for him. But once you collected as much intelligence as you possibly can, you can visit a distro wiki, go Google, fill up a Bugzilla or some other automated error report if it pops up, and, best of all, contact developers. If you did your homework thoroughly, your contribution is highly valuable. It may fail to resolve your trouble, but is going to help many other people.
35 • @34 Igor: (by dragonmouth on 2020-09-02 12:48:58 GMT from United States)
"In free world there is place for almost everything and everyone."
IOW, you want tolerance and acceptance for BTRFS but you are not willing to tolerate and accept those that do not wish to use BTRFS for whatever reason.
36 • Daily user of BTRFS for 10 years (by Dxvid on 2020-09-02 13:00:14 GMT from Sweden)
I've used BTRFS daily for about 10 years both on servers and desktop computer and always find it amusing to read comments from noobs about BTRFS not being stable or being bad in various ways, people spread myths in forums for some reason. I think the "5G spreads viruses and flat earth type of people" need to calm down and try the file system for a few years instead of badmouthing a file system they obviously have very little experience with. In general you shouldn't believe comments from people with little or no experience.
The best feature of BTRFS is the snapshots (handled with snapper in OpenSUSE/SUSE), so that you can go back to a previously working state if something goes bad. For example I had a patch making an email server stop working (happened in Ubuntu) and a patch hindering network traffic to/from virtual machines (happened in OpenSUSE), and NVIDIA proprietary drivers not working (happened many times in various distros). In less than a minute you have a working server/desktop again after a patch broke some feature. No need to try to get backups to work or manually trying to undo the patch and find the problem for hours on the command-line. The second best is CRC and possibility to fix errors. The third best is the possibility to find duplicates and save space by deduplication. If the disk is getting full you can deduplicate it and suddenly you have freed up a TB of space or two.
The only disadvantage I've found in 10 years is that the CPU consumption goes up, so it's best to use BTRFS on high end machines, especially if there's constant disk writing causing a lot of CRC calculations it's important to have a good CPU. However all file systems with advanced features will use more resources, so NTFS, ZFS and BTRFS will require a slightly more powerful computer than for example XFS or Ext4. If you also turn on compression, RAID5/6 or encryption you need a high end CPU in your computer/server (and/or a dedicated RAID card)
37 • Better Poll Question (by M.Z. on 2020-09-02 22:41:11 GMT from United States)
I think this weeks DW comments bring up a better poll question:
Have you tried BTRFS & if so how was it?
[x] Yes, & it worked well
[ ] Yes, but it had some issues
[ ] Yes, but it caused big problems
[ ] No, I never tried BTRFS
It might clear up some misconceptions. If I Ctrl-F on the old poll questions I notice that about 20% of respondents use BTRFS, though that mostly implied current use.
38 • New Poll (by Friar Tux on 2020-09-02 23:05:41 GMT from Canada)
@37 (MZ) I would vote the third one. (Yes, but it caused big problems.) I HAVE come to the conclusion, though, that hardware may play a part in the 'problems'. The first time I tried BTRFS was on an older machine and yes, 'big problems'. The next try out was on a newer laptop and the issues were there, but it seemed to me, not as problematic. I still play with it, but for my everyday-gotta-get-stuff-done-system I need something stable. Still, I can't help hoping that they can make BTRFS stable and work well enough to someday become the default FS.
39 • Fedora (by Banana Bob on 2020-09-03 10:40:23 GMT from United States)
I really wanted to run Fedora on my laptop. But, I couldn't get copy and paste to work. It turns out this is a bug caused by SELinux being set to enforcing mode by default. The problem went away when I set SELinux to permissive mode, but I had already given up on Fedora by then. Now I use Linux Mint instead, because everything just works with no hassle.
40 • more of the other words (by Igor on 2020-09-03 11:43:16 GMT from Croatia)
@dragonmouth (35):
Statement 1: "I am using ext4 and I am going to stick with it because it serves me well and covers all my needs." Assertion of personal preference. Credible. Commending a software. Goes.
Statement 2: "This distro is causing troubles all the time, and the user wastes her time mending it instead of using it." Statement pleads to universal validity, therefore almost certainly false. Derogatory. No go.
Statement 3: "Btrfs is superior to OpenZFS, not to even mention ext4 ReiserFS, or JFS. It should be used by all the distros out there." Again universally quantified. Almost imposible to verify, but most probably false. Confronts good softwares. Partisan. Campaigns against diversity. No go.
Is it any clearer now?
41 • Bunsen Labs (by noar on 2020-09-03 12:06:16 GMT from United States)
@9 - yes that 375m was an eye raiser. When I tried it out, the 32-bit smaller iso, it came in on the lean side of 200m. Installed for testing had it running at about 160-170m.
So I suspect that the install Jesse did had a few more things running in the background. My daily goto Openbox installation runs at boot in a 128-132m footprint, so the fault is not Openbox.
As to why Bunsen Labs is not my goto, I have a dislike for systemd, I know, irrational as that may be. But I always look to Bunsen Labs for the ideas and tools that have made Hydrogen to Lithium such fine distros, and freely admit to 'stealing' those items for my own personal use.
42 • @40 Igor: (by dragonmouth on 2020-09-03 12:39:30 GMT from United States)
You continue to miss or disregard on purpose the main point. Linux is about CHOICE. I, and many others, choose to use ext4 while you, and others, choose to use BTRFS. So use what you want BUT just because you love BTRFS, do not denigrate others for using something else. I use Linux because I refuse to be dictated to by Microsoft, Apple or anybody else.
43 • fus do rah (by fonz on 2020-09-03 12:56:44 GMT from Indonesia)
i thought they were dumping BTRFS a while ago, seems i got my gossip mixed a bit. tried fedora a long time ago, but it didnt work well as i had trouble getting my drivers up and running. it may be as simple as many of the others now, but yeah, i guess im not a fedora person.
BTRFS did work well when i was using geckolinux (opensuse) TW. i could (while following guides) recover from panics and whatnot. i gave up after a year or so later after tumbleweed kept tumbling and stumbling and fumbling whereas sid and arch have yet to panic once after years.
44 • BTRFS (by Otis on 2020-09-03 18:39:12 GMT from United States)
@37 @38 Another poll response could be "Yes I had problems running BTRFS but I'm not sure if that file system is what caused those problems."
I have to admit that of the dozens of distros I have removed in frustration I'd say that the highest percentage of them were exhibiting issues repeatedly either during install or within a day or so, or much shorter, of use. The BTRFS attempts do seem to be a large portion of those failures but you can argue me down as I have not kept tract that closely, although yes I do have my suspicions.
45 • Matter of Perspective (by M.Z. on 2020-09-03 21:45:35 GMT from United States)
@38
Truth be told I could fall into any of the three categories I mentioned based on my experiences with both my laptop (buggy with certain write operations) & with my desktop, which ran BTRFS flawlessly. The laptop actually crashes with large rsync operations & when trying to do a live install (I have to pull the drive & connect it to the desktop to upgrade to a new distro). Regardless of the general laptop issues, the experience with the desktop was so smooth that it feels more true to say I had a good experience with BTRFS.
@44 - Not a bad point, but I feel like that would likely fall in to the 'had issues' category, as it is qualified & less sure than the others. A good poll gives a few general categories & doesn't dive so deep into nuance that you get overwhelmed with options, so it can be a matter of perspective.
46 • Bunsen Labs (by BK on 2020-09-05 04:52:31 GMT from United States)
+1 for Bunsen Labs Lithium
I was looking for a lightweight and functional distro to run in a VM and while I do agree that naming conventions don't make it easy but it all works and manages to look much more polished than I expected.Enough good stuff for me to consider replacing Mint as my main/host.
47 • @39 • Fedora (by Banana Bob) (by whoKnows on 2020-09-05 10:45:25 GMT from Switzerland)
“I really wanted to run Fedora on my laptop. But, I couldn't get copy and paste to work. It turns out this is a bug caused by SELinux being set to...”
That's not the Fedora issue. Fedora has no issues with copy & paste function.
Probably only the default settings (touchpad click is disabled by default) or some temporary kernel issue.
https://fedoraproject.org/wiki/How_to_enable_touchpad_click
https://www.linuxquestions.org/questions/fedora-35/fedora-28-gnome-touchpad-problem-4175638954/
48 • Dynamic linking on memory contrained systems (by .so on 2020-09-05 14:21:11 GMT from Germany)
But what about memory utilization? Will a memory constrained system work better with statically or dynamically linked libraries? Less size for programs might result in more buffers, and less swapping maybe?
Number of Comments: 48
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 1099 (2024-12-02): AnduinOS 1.0.1, measuring RAM usage, SUSE continues rebranding efforts, UBports prepares for next major version, Murena offering non-NFC phone |
| • Issue 1098 (2024-11-25): Linux Lite 7.2, backing up specific folders, Murena and Fairphone partner in fair trade deal, Arch installer gets new text interface, Ubuntu security tool patched |
| • Issue 1097 (2024-11-18): Chimera Linux vs Chimera OS, choosing between AlmaLinux and Debian, Fedora elevates KDE spin to an edition, Fedora previews new installer, KDE testing its own distro, Qubes-style isolation coming to FreeBSD |
| • Issue 1096 (2024-11-11): Bazzite 40, Playtron OS Alpha 1, Tucana Linux 3.1, detecting Screen sessions, Redox imports COSMIC software centre, FreeBSD booting on the PinePhone Pro, LXQt supports Wayland window managers |
| • Issue 1095 (2024-11-04): Fedora 41 Kinoite, transferring applications between computers, openSUSE Tumbleweed receives multiple upgrades, Ubuntu testing compiler optimizations, Mint partners with Framework |
| • Issue 1094 (2024-10-28): DebLight OS 1, backing up crontab, AlmaLinux introduces Litten branch, openSUSE unveils refreshed look, Ubuntu turns 20
| | • Issue 1093 (2024-10-21): Kubuntu 24.10, atomic vs immutable distributions, Debian upgrading Perl packages, UBports adding VoLTE support, Android to gain native GNU/Linux application support |
| • Issue 1092 (2024-10-14): FunOS 24.04.1, a home directory inside a file, work starts of openSUSE Leap 16.0, improvements in Haiku, KDE neon upgrades its base |
| • Issue 1091 (2024-10-07): Redox OS 0.9.0, Unified package management vs universal package formats, Redox begins RISC-V port, Mint polishes interface, Qubes certifies new laptop |
| • Issue 1090 (2024-09-30): Rhino Linux 2024.2, commercial distros with alternative desktops, Valve seeks to improve Wayland performance, HardenedBSD parterns with Protectli, Tails merges with Tor Project, Quantum Leap partners with the FreeBSD Foundation |
| • Issue 1089 (2024-09-23): Expirion 6.0, openKylin 2.0, managing configuration files, the future of Linux development, fixing bugs in Haiku, Slackware packages dracut |
| • Issue 1088 (2024-09-16): PorteuX 1.6, migrating from Windows 10 to which Linux distro, making NetBSD immutable, AlmaLinux offers hardware certification, Mint updates old APT tools |
| • Issue 1087 (2024-09-09): COSMIC desktop, running cron jobs at variable times, UBports highlights new apps, HardenedBSD offers work around for FreeBSD change, Debian considers how to cull old packages, systemd ported to musl |
| • Issue 1086 (2024-09-02): Vanilla OS 2, command line tips for simple tasks, FreeBSD receives investment from STF, openSUSE Tumbleweed update can break network connections, Debian refreshes media |
| • Issue 1085 (2024-08-26): Nobara 40, OpenMandriva 24.07 "ROME", distros which include source code, FreeBSD publishes quarterly report, Microsoft updates breaks Linux in dual-boot environments |
| • Issue 1084 (2024-08-19): Liya 2.0, dual boot with encryption, Haiku introduces performance improvements, Gentoo dropping IA-64, Redcore merges major upgrade |
| • Issue 1083 (2024-08-12): TrueNAS 24.04.2 "SCALE", Linux distros for smartphones, Redox OS introduces web server, PipeWire exposes battery drain on Linux, Canonical updates kernel version policy |
| • Issue 1082 (2024-08-05): Linux Mint 22, taking snapshots of UFS on FreeBSD, openSUSE updates Tumbleweed and Aeon, Debian creates Tiny QA Tasks, Manjaro testing immutable images |
| • Issue 1081 (2024-07-29): SysLinuxOS 12.4, OpenBSD gain hardware acceleration, Slackware changes kernel naming, Mint publishes upgrade instructions |
| • Issue 1080 (2024-07-22): Running GNU/Linux on Android with Andronix, protecting network services, Solus dropping AppArmor and Snap, openSUSE Aeon Desktop gaining full disk encryption, SUSE asks openSUSE to change its branding |
| • Issue 1079 (2024-07-15): Ubuntu Core 24, hiding files on Linux, Fedora dropping X11 packages on Workstation, Red Hat phasing out GRUB, new OpenSSH vulnerability, FreeBSD speeds up release cycle, UBports testing new first-run wizard |
| • Issue 1078 (2024-07-08): Changing init software, server machines running desktop environments, OpenSSH vulnerability patched, Peppermint launches new edition, HardenedBSD updates ports |
| • Issue 1077 (2024-07-01): The Unity and Lomiri interfaces, different distros for different tasks, Ubuntu plans to run Wayland on NVIDIA cards, openSUSE updates Leap Micro, Debian releases refreshed media, UBports gaining contact synchronisation, FreeDOS celebrates its 30th anniversary |
| • Issue 1076 (2024-06-24): openSUSE 15.6, what makes Linux unique, SUSE Liberty Linux to support CentOS Linux 7, SLE receives 19 years of support, openSUSE testing Leap Micro edition |
| • Issue 1075 (2024-06-17): Redox OS, X11 and Wayland on the BSDs, AlmaLinux releases Pi build, Canonical announces RISC-V laptop with Ubuntu, key changes in systemd |
| • Issue 1074 (2024-06-10): Endless OS 6.0.0, distros with init diversity, Mint to filter unverified Flatpaks, Debian adds systemd-boot options, Redox adopts COSMIC desktop, OpenSSH gains new security features |
| • Issue 1073 (2024-06-03): LXQt 2.0.0, an overview of Linux desktop environments, Canonical partners with Milk-V, openSUSE introduces new features in Aeon Desktop, Fedora mirrors see rise in traffic, Wayland adds OpenBSD support |
| • Issue 1072 (2024-05-27): Manjaro 24.0, comparing init software, OpenBSD ports Plasma 6, Arch community debates mirror requirements, ThinOS to upgrade its FreeBSD core |
| • Issue 1071 (2024-05-20): Archcraft 2024.04.06, common command line mistakes, ReactOS imports WINE improvements, Haiku makes adjusting themes easier, NetBSD takes a stand against code generated by chatbots |
| • Issue 1070 (2024-05-13): Damn Small Linux 2024, hiding kernel messages during boot, Red Hat offers AI edition, new web browser for UBports, Fedora Asahi Remix 40 released, Qubes extends support for version 4.1 |
| • Issue 1069 (2024-05-06): Ubuntu 24.04, installing packages in alternative locations, systemd creates sudo alternative, Mint encourages XApps collaboration, FreeBSD publishes quarterly update |
| • Issue 1068 (2024-04-29): Fedora 40, transforming one distro into another, Debian elects new Project Leader, Red Hat extends support cycle, Emmabuntus adds accessibility features, Canonical's new security features |
| • Issue 1067 (2024-04-22): LocalSend for transferring files, detecting supported CPU architecure levels, new visual design for APT, Fedora and openSUSE working on reproducible builds, LXQt released, AlmaLinux re-adds hardware support |
| • Issue 1066 (2024-04-15): Fun projects to do with the Raspberry Pi and PinePhone, installing new software on fixed-release distributions, improving GNOME Terminal performance, Mint testing new repository mirrors, Gentoo becomes a Software In the Public Interest project |
| • Issue 1065 (2024-04-08): Dr.Parted Live 24.03, answering questions about the xz exploit, Linux Mint to ship HWE kernel, AlmaLinux patches flaw ahead of upstream Red Hat, Calculate changes release model |
| • Issue 1064 (2024-04-01): NixOS 23.11, the status of Hurd, liblzma compromised upstream, FreeBSD Foundation focuses on improving wireless networking, Ubuntu Pro offers 12 years of support |
| • Issue 1063 (2024-03-25): Redcore Linux 2401, how slowly can a rolling release update, Debian starts new Project Leader election, Red Hat creating new NVIDIA driver, Snap store hit with more malware |
| • Issue 1062 (2024-03-18): KDE neon 20240304, changing file permissions, Canonical turns 20, Pop!_OS creates new software centre, openSUSE packages Plasma 6 |
| • Issue 1061 (2024-03-11): Using a PinePhone as a workstation, restarting background services on a schedule, NixBSD ports Nix to FreeBSD, Fedora packaging COSMIC, postmarketOS to adopt systemd, Linux Mint replacing HexChat |
| • Issue 1060 (2024-03-04): AV Linux MX-23.1, bootstrapping a network connection, key OpenBSD features, Qubes certifies new hardware, LXQt and Plasma migrate to Qt 6 |
| • Issue 1059 (2024-02-26): Warp Terminal, navigating manual pages, malware found in the Snap store, Red Hat considering CPU requirement update, UBports organizes ongoing work |
| • Issue 1058 (2024-02-19): Drauger OS 7.6, how much disk space to allocate, System76 prepares to launch COSMIC desktop, UBports changes its version scheme, TrueNAS to offer faster deduplication |
| • Issue 1057 (2024-02-12): Adelie Linux 1.0 Beta, rolling release vs fixed for a smoother experience, Debian working on 2038 bug, elementary OS to split applications from base system updates, Fedora announces Atomic Desktops |
| • Issue 1056 (2024-02-05): wattOS R13, the various write speeds of ISO writing tools, DSL returns, Mint faces Wayland challenges, HardenedBSD blocks foreign USB devices, Gentoo publishes new repository, Linux distros patch glibc flaw |
| • 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 |
| • 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 | 
Caos Linux
Caos Linux NSA was a light-weight, fast, efficient, stable, and secure distribution of Linux that was appropriate for servers, compute nodes, network appliances, and even the latest desktop and laptop computers. It was maintained and managed by a team of computer science experts with numerous proven skills. With resources pooled together, they created a multifunctional operating system with mission critical dependability. Caos Linux was designed to run on all x86_64 and i386 hardware ranging from clusters and servers to production level appliances to personal desktops and laptops. Supporting a wide variety of software, Caos Linux was based on the best aspects of GNU/Linux and has full binary compatibility with the most popular enterprise distribution of Linux.
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.
|
|
• 
• 
• 
• 
• 
• 
• 
