 DistroWatch Weekly |
| DistroWatch Weekly, Issue 1084, 19 August 2024 |
Welcome to this year's 34th issue of DistroWatch Weekly!
Many distributions these days seek to offer an experience which can be described as an easy-to-use Arch Linux. One such project is Liya, an Arch-based distribution that uses the Calamares system installer and the Cinnamon desktop. Jeff Siegel recently took Liya for a test drive and reported on his findings. Read on to learn his thoughts on the distribution in our Feature Story. In our News section we share new performance improvements coming to the Haiku project along with an announcement Gentoo is dropping IA-64 processor support next month. Plus we talk about a major collection of updates coming to Redcore users and challenges this project is facing. This week we also talk about encryption, particularly how to encrypt multiple filesystems on the same hard drive. Do you use full disk or home directory encryption? Let us know in this week's Opinion Poll. Plus we are pleased to share the new releases of the past week and list the torrents we are seeding. We wish you all a fantastic week and happy reading!
This week's DistroWatch Weekly is presented by TUXEDO Computers.
Content:
|
| Feature Story (By Jeff Siegel) |
Liya 2.0
Look upon Liya, a rolling release distribution based on Arch Linux, and prepare to be amazed. It's slick. It's snappy. And it somehow manages to give Arch an intuitive graphical interface for those of us who don't need to use the command line to be fulfilled as a human being.
Liya 2.0 -- The Cinnamon desktop
(full image size: 455kB, resolution: 1366x768 pixels)
Most amazing, it's a one-person operation, the work of Sayed M. Hisham, who seems to have put his heart and soul - and who knows what else - into producing Liya. Who else would offer this warning? "Liya Is Not For Users Who ... Are distro-hoppers." The ISO, download, and installation procedure are as capable as anything from Fedora or Ubuntu, and that's not necessarily easy to do.
So why isn't this this a completely positive review of Liya 2.0 (codenamed Aadnya), after a week or so tinkering with Liya? Because it took me a week to navigate the balky software updater/installer, which kept throwing errors related to a series of corrupted keyring PGP signatures. The instructions for fixing the problem were incomplete and contradictory; I'd do one thing, which didn't work, and then have find another approach, which also didn't work.
And if one takes a week to figure out how to install new software and update the existing installation, that kind of puts a damper on using Liya, doesn't it?
Nevertheless, Liya is worth writing about because - assuming Hisham can clean up the documentation - it offers something that seems to fill a need. He understands this, writing that Liya's goal is to provide an Arch-based distro that isn't bloated, works on lower-spec hardware, and combines a clean and efficient interface with quality performance.
Where's the update?
The update and installation flummox was about the last thing I expected after running Liya without any trouble in VirtualBox and then installing it on my test machine. Both went off without a hitch; in fact, it was one of the smoothest VirtualBox sessions I've had when writing a DistroWatch review. The live version of Liya didn't hang up, make the screen go goofy, or any of the rest. It just worked.
Even better: it took just seven minutes to install the 64-bit Cinnamon desktop edition, which is provided through a 3.6GB ISO (there is also a 4.1GB MATE desktop edition). Requirements are 4GB of RAM, a dual core CPU, and 20GB of hard drive space - hardly overwhelming specs. Liya comes with systemd 256, Cinnamon 6.2.2 and it updates to the 6.10.0-rc6-1 mainline kernel after installation.
The Calamares installer did what it was supposed to do without any problems, even giving the option to install the distro on an ext4 or Btrfs filesystem (I chose the latter), In fact, it restored my wireless connection and remembered my screen resolution, as well as rebooting without a problem while removing the installation media, which sometimes hangs up with other distros.
Liya 2.0 -- The Calamares system installer
(full image size: 615kB, resolution: 1920x1080 pixels)
The trouble started when I went to update the system after installation. I ran the Pamac software updater/installer, and got an error: "Failed to commit transaction/Failed to retrieve some files." I messed around with the settings, figuring a repository was set up incorrectly. No joy there, either. So I clicked the Forum desktop icon, which took me to the distro's wiki. Listed were three terminal commands to run after installation: refreshing the mirror list and keyring and then updating the system with "sudo pacman -Syu".
Liya 2.0 -- Failing to update packages
(full image size: 249kB, resolution: 1366x768 pixels)
"Ah," I thought, "it's based on Arch, so my Debian-centric mind just didn't understand what needed to be done." But the provided commands from the wiki didn't work, either - the terminal kept spitting out lines about untrusted software keys and didn't do any updating.
At this point, I thought about moving on, but - to be completely honest - I didn't want to admit that an Arch-based distro had beaten me. So I put Liya away for a day or so, planning to return with a fresh mindset and to undertake some intensive DuckDuckGo-ing.
This process went on for about a week, with no more success. The only related entry in the Liya forum was more than a year old, but didn't offer a solution. And nothing turned up during various Internet searches, save for some hints that the same problem existed with Kali Linux,
And then, for no particular reason, I looked yet again at the almost too spartan Liya website. At the very bottom of the home page, there was an 11-step installation guide. I had not paid much attention to it before, since it said to use Rufus to install Liya, and I don't use Windows. But the 11th step was the difference: "After the installation, run fixpacrepo from the terminal." Which I did, and - save for one remaining annoyance where clicking "shut down" on the menu only logs out - Liya was ready to run as a daily driver.
Software and apps
The Cinnamon desktop works nicely in Liya - no stutters, no hang-ups, and a minimum of spinning wheels after launching an app. Cinnamon extensions are added through a dedicated app, and I installed the weather extension without trouble. And it is light to use, with only 8% on the CPU and 1,400MB of memory used while a YouTube video was running at the same time as a song played on the music player.
Liya 2.0 -- The Cinnamon application menu
(full image size: 339kB, resolution: 1366x768 pixels)
The default applications are a mix of Cinnamon, Arch and its underpinnings, including access to the AUR, and Hisham's selections. Cinnamon contributions include the Nemo file manager and its Actions Centre; the Pix photo viewer; xed text editor; the GNOME Terminal; and the Celluloid video player. Hisham has chosen Brave as the browser, Geary as the e-mail client, and the free version of OnlyOffice as the office suite. Also included are the Ulauncher application launcher; Vim, for those who prefer that sort of thing; Deluge for BitTorrent; Bleachbit (for the intrepid); and Exaile for music.
Brave and OnlyOffice are intriguing choices, though Ulauncher and Geary aren't common, either. Brave seemed to work as it was supposed to, though it didn't seem any lighter than Firefox. I know OnlyOffice a little (I've worked my way through most office suites, free and paid, in a vain attempt to liberate myself from LibreOffice's annoyances), and it's fine, but not appreciably different from LibreOffice. Geary, thanks to Google's security witchcraft, wouldn't recognize the Gmail account I use for these reviews, so it was easier to set up a Brave progressive web app (PWA) and run Gmail through it. Ulauncher was a pleasant surprise, though I wish it was as easy to set up to access files and documents as it is on the Albert launcher.
Liya 2.0 -- Running OnlyOffice
(full image size: 113kB, resolution: 1366x768 pixels)
One word here about Hardinfo2, a system information and benchmark utility. Usually, one of the Neofetch clones suffices for my purposes, but Hardinfo2 is much more complete, offers the information in a user-friendly way, and allowed me to run fun, if useless, benchmarks for my older test machine.
In the end, the problems with Liya aren't about the distro itself, which is so simple to use it's almost as if it's not based on Arch. Believe it or not, there's as little need to use the command line as there is on Ubuntu. And yes, I can see using it on my older hardware as a daily driver, even though it likely does far more than I need it to do. That it was a rolling release also didn't seem to matter. Once I got everything working, nothing gummed up or to acted wonky.
Rather, the problem is - sadly - typical of so many one-person and small group Linux efforts. There's so much to do in just building the damned thing that so much else falls through the cracks. Yes, I probably should have found the instructions to run fixpacrepo to rebuild the repos and update the GPG keys sooner than I did. And, almost certainly, an Arch devotee would have known to do it as matter of course.
On the other hand, for anyone coming to Arch from elsewhere, which seems to be one of Liya's goals, one set of accurate and complete instructions located in every place anyone would look - home page, wiki, forum, whatever - is necessary, even if it's a lot of work. That's one of the basics in running a distro. Hopefully, Hisham can take that next step, since Liya deserves all the attention it can get.
* * * * *
Hardware used for this review
My physical test equipment for this review was a Dell Latitude E7440 laptop with the following specifications:
- Processor: Intel i7-4600U
- Storage: 256GB SSD
- Memory: 8GB of RAM
- Networking: Qualcomm Atheros AR9485
- Display: Intel HD Graphics 4400
When he is not testing out new versions of Linux distributions, Jeff Siegel can be found writing about all things related to wine at Wine Curmudgeon.
* * * * *
Visitor supplied rating
Liya has a visitor supplied average rating of: 5/10 from 4 review(s).
Have you used Liya? You can leave your own review of the project on our ratings page.
|
| Miscellaneous News (by Jesse Smith) |
Haiku introduces performance improvements, Redcore merges major upgrade, Gentoo dropping IA-64 support
The Haiku project has been making progress on multiple fronts. Developer x512 recently posted they have a mostly-functioning port of the Firefox web browser and offered screenshots of Firefox running on the open source operating system.
Meanwhile the project's monthly newsletter talks about performance and profile improvements: "Haiku has a built-in CPU time profiler (just called profile.) Unfortunately, it's been rather broken for years, regularly outputting data that was either empty or just didn't make any sense. In order to use it to try and track down some of the other bottlenecks, I spent a bunch of time fixing various bugs in it, as well as the debugger support code that it relies on to function, including to stack trace collection, buffer flushing, symbol lookup, scheduler callbacks, image load reporting, and more. I also implemented userspace-only profiling (ignoring kernel stack frames entirely), fixed some output buffer sizing issues, and fixed a race condition in thread resumption that also affected strace. While it isn't perfect, it's much better than before, and can now be used to profile applications and the kernel to see where CPU time is being spent; and notably it now checks the thread's CPU time counters to detect if it 'missed' profiling ticks, and if so how many."
* * * * *
People who run Redcore Linux should prepare for a major upgrade of the rolling release project. Part of the flood of updates, for new and existing users, comes from time constraints. " I have promised I will merge all the changes from branch next and release an ISO at the same time, however I cannot keep that promise and I apologise. Producing an ISO image is a time consuming endeavour. It takes 3 hours to spin, followed by days of testing. If something goes wrong, I have to start from scratch. I understand many of you would prefer not to go through a lengthy update, however, for the time being, I cannot dedicate a few days to produce a new release. Branch master is, as of this post, almost 3 months behind, and it falls even further behind each time I push updates into branch next. As mentioned above, pushing frequent updates is easy, producing a new release, not so much. At the same time, holding a branch behind with the hope I might get some time to produce a release, is unreasonable. As a result, I have decided to merge all the goodies from branch next, into branch master, aka Plasma 6, LXQt 2.0, new system profile, and a new binary format." Instructions for how to handle the new flood of updates are covered in the project's blog post.
* * * * *
The Gentoo project has announced it will be dropping support for the IA-64 CPU architecture in the near future, following the Linux kernel phasing out support. "Following the removal of IA-64 (Itanium) support in the Linux kernel and glibc, and subsequent discussions on our mailing list, as well as a vote by the Gentoo Council, Gentoo will discontinue all ia64 profiles and keywords. The primary reason for this decision is the inability of the Gentoo IA-64 team to support this architecture without kernel support, glibc support, and a functional development box (or even a well-established emulator). In addition, there have been only very few users interested in this type of hardware." The change will take place in early September 2024.
* * * * *
These and other news stories can be found on our Headlines page.
|
| Questions and Answers (by Jesse Smith) |
Dual boot with encryption
Shields-up asks: How can I make it so the files from one Linux distro on my laptop can't be accessed by another distro on the same laptop? I only have one hard drive in the laptop.
DistroWatch answers: When you are trying to protect one operating system from another on the same hardware, you pretty much need to use encryption. Depending on which files you want to protect, you might take different approaches to using encryption. For instance, if you are only worried about protecting your user's files (data stored under your home directory) then you could use user directory encryption or encrypt the /home partition only. However, if you are worried about one operating system compromising another, not just reading the contents of private data on the filesystem, then you'll need full disk/partition encryption.
The challenge we then face is few distribution system installers make it easy to set up multiple distributions on the same hard drive, both with encrypted root filesystems. Some projects, such as Ubuntu, make it easy to wipe an entire drive and encrypt the operating system's disk, but they don't really offer a smooth way to install two operating systems side-by-side, with both of them encrypted. It's generally assumed that if you want to protect your operating system's data using encryption, then you won't install a second operating system which might be used to compromise it.
There are a few suggestions I can make for working around this assumption.
The first and easiest option is to set up your preferred distribution normally with full disk encryption. Then install your second distribution inside a virtual machine running on the original (host) distribution. This won't, technically, provide dual boot capabilities, so if that is something you really need this won't help. However, in the vast majority of cases, installing a distribution in a virtual machine and using full disk encryption in the VM is the most practical way to go. The host won't see the encrypted files inside the virtualized guest and the guest won't see the host's files.
The only situations where this will not work are if you really need the second operating system to have direct access to the hardware or you have an extremely limited amount of RAM available.
Another option would be to plug in an external hard drive to your laptop. Then install one distribution per drive, each of them using full disk encryption. Most laptops will boot from an external drive and that way each distro can have its own disk. For added security, when not using the distribution on the external drive, you could unplug it, guaranteeing the distro on the internal drive can't see the second distro at all.
The performance of the distro on the second drive will be reduced when reading from the disk, and you'll have some up front costs for the external drive, but this is probably the easiest approach if you absolutely need to dual boot.
Since most system installers do not handle setting up dual-boot, encrypted operating systems gracefully, a third option is to do the disk partitioning and encrypting ourselves. We can set up encrypted disk partitions manually and then try to install our distribution of choice into the encrypted volume. This usually only works well with highly manual distributions, such as Arch Linux or in cases where the user knows how to set up a distribution manually using a live media. However, for those who are brave enough to go this route and want full control, the Arch wiki has tutorials for setting up encrypted partitions, ZFS, and LVM volumes.
This last option is certainly the most complex and involves the most work. However, if the situation really requires dual booting, full filesystem encryption, and cannot involve a second hard drive, this is probably the best option left to you.
* * * * *
Additional answers can be found in our Questions and Answers archive.
|
| Released Last Week |
RebeccaBlackOS 2024-08-12
RebeccaBlackOS is a Debian-based live distribution which can be used to run Wayland desktop sessions. The project's latest release features a number of upgrades, including swapping out Qt5 for Qt6 and dropping support for 32-bit processors. "New in these ISOs since 2023-01-16: Only 64-bit ISOs are made as QtWebEngine refuses to build in 32 bit chroots. Config files in packages built by checkinstall are correctly marked as config files. Files from the build process are all part of packages, and are not ophaned. The number of potential file conflicts with unintalled packages from the tier 1 Debian repo has been vastly reduced. The few that remain are properly handled by dpkg-divert. Linux 6.10 is built, and drm_panic is enabled. The ttynull driver is enabled. Linux is patched directly to use /dev/ttynull as the default console device. This allows systemd to correctly log to /dev/console. The tier 1 packages are now Debian Bookworm. Qt5 is now removed in favor of Qt6." Additional information can be found in the project's release notes.
Tails 6.6
The Amnesic Incognito Live System (Tails) is a Debian-based live DVD/USB with the goal of providing complete Internet anonymity. The project's latest release, Tails 6.6, is focused on fixing issues and improving the persistent storage experience. "Fixed problems: Persistent storage: Increase the maximum waiting time to 4 minutes when unlocking the Persistent Storage before returning an error. Made the creation of the Persistent Storage more robust after starting a Tails USB stick for the first time. Prevent the Persistent Storage settings from freezing after opening a link to the documentation. Prevent Additional Software from crashing when installing virtual packages. Networking: Fix connecting to the Tor network using default bridges. Allow enabling multiple network interfaces again." The release announcement offers additional information.
deepin 23
The deepin distribution is based on Debian and features the custom-made Deepin Desktop Environment (Deepin DE). The project's latest release is version 23 which introduces atomic updates and support for a wider range of CPU architectures. The new CPU support includes install media and packages for ARM and RISC-V processors. "The system repository packages have been comprehensively upgraded to enhance stability and security, and better support new hardware and architectures such as ARM64, RISC-V, and LoongArch64. Established a new V23 repository for the upgrade of over 8,000 core packages. Introduced a new installation and upgrade mechanism to reduce disk space occupation during whole disk installation. Provided a flexible upgrade backup mechanism to ensure user rollback capability in case of upgrade anomalies, and offered users the ability to manage multiple versions. Optimized system backup solutions to reduce disk space usage compared to the previous A/B partition scheme. Added the "Atomic Update" capability, allowing users to flexibly roll back or switch system versions based on backup restore points." Additional details can be found in the project's release announcement.
deepin 23 -- The Deepin desktop and application menu
(full image size: 2.6MB, resolution: 1920x1440 pixels)
ExTiX 24.8
ExTiX is a distribution in the Debian family which offers alterative desktop environments. The project's latest release, ExTiX 24.8, is based on deepin 23. "New functions etc. in ExTiX 24.8 'Deepin': 1. VirtualBox Guest Additions are not pre-installed. No real need for them since you can run ExTiX in full screen in VirtualBox by just changing the screen resolution. 2. You can run ExTiX from RAM. Use boot alternative 2 (load to RAM) or Advanced. A wonderful way to run Linux if you have enough RAM. Everything will be super fast. When ExTiX has booted up you can remove the DVD or USB stick. 3. You can use Deepin Installer as an alternative to Refracta Installer. Use Deepin Installer preferable on UEFI computers if you want/need to install or reinstall GRUB. 4. I have installed Google Chrome 127.0.6533.119-1 as a replacement for Deepin's Browser, which suddenly can be in Chinese. 5. I've added Synaptic Package Manager. A must I think. Watch a screenshot when Synaptic is running. 6. You can watch Netflix while running Google Chrome...." Additional details can be found in the project's release announcement.
* * * * *
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: 3,055
- Total data uploaded: 45.1TB
|
| Upcoming Releases and Announcements |
|
Summary of expected upcoming releases
|
| Opinion Poll (by Jesse Smith) |
Do you encrypt your root filesystem or home directories?
In our Questions and Answers column we talked about disk encryption. When it comes to protecting data there are a few approaches people can take. One is to encrypt everything on the disk, including the operating system and user files. Some people prefer to just encrypt the data files under their account. Others may not encrypt any parts of the filesystem and, instead, use encrypted file vaults for sensitive information. We'd like to hear which approach to encryption you use.
You can see the results of our previous poll on types of smartphones our readers use in our previous edition. All previous poll results can be found in our poll archives.
|
Full disk encryption or home directory encryption?
| I use full disk encryption: | 417 (12%) |
| I encrypt home directories only: | 90 (3%) |
| I use file vaults: | 100 (3%) |
| I use a combination of the above: | 89 (3%) |
| I use another approach: | 69 (2%) |
| I use none of the above: | 2595 (77%) |
|
|
| Website News |
New distributions added to waiting list
- BredOS. BredOS is a user-friendly Arch-based Linux distribution specifically designed for ARM-based single board computers (SBCs).
- Red OS. Red OS is a Russian distribution for servers and workstations. The distribution offers KDE, GNOME, and MATE editions for the x86_64 architecture.
* * * * *
DistroWatch database summary
* * * * *
This concludes this week's issue of DistroWatch Weekly. The next instalment will be published on Monday, 26 August 2024. Past articles and reviews can be found through our Weekly Archive and Article Search pages. 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)
|
|
| Tip Jar |
If you've enjoyed this week's issue of DistroWatch Weekly, please consider sending us a tip.
(Tips this week: 1, value: US$20) |
|
|
|
 bc1qxes3k2wq3uqzr074tkwwjmwfe63z70gwzfu4lx  lnurl1dp68gurn8ghj7ampd3kx2ar0veekzar0wd5xjtnrdakj7tnhv4kxctttdehhwm30d3h82unvwqhhxarpw3jkc7tzw4ex6cfexyfua2nr  86fA3qPTeQtNb2k1vLwEQaAp3XxkvvvXt69gSG5LGunXXikK9koPWZaRQgfFPBPWhMgXjPjccy9LA9xRFchPWQAnPvxh5Le paypal.me/distrowatchweekly • patreon.com/distrowatch |
|
| Extended Lifecycle Support by TuxCare |
|
|
| Reader Comments • Jump to last comment |
1 • disk encryption (by Name (mandatory) on 2024-08-19 01:24:31 GMT from United States)
I'm noob. If something goes wrong with encryption, I would not know how to help myself. Hence, my disks are not encrypted
2 • Liya (by Kilroy the Great on 2024-08-19 02:57:17 GMT from United States)
"The system is intended to be easy to use, easy to explore, and distraction-free." Would be nice to see how it compares with Endeavour, Manjaro, Garuda, or a bunch of other easy to install, easy to use, etc. Arch-based distros.
3 • Disk encryption (by Alamedated on 2024-08-19 03:04:14 GMT from United States)
I am afraid of disk encryption. My work computer encrypts the disk and it takes them about 15 minutes to boot up. It is a bit irrational that I am afraid to encrypt a disk that I don't mind wiping out.
Thank you for the poll. I am going to try disk encryption!
4 • If you use disk encryption.... (by eco2geek on 2024-08-19 03:47:18 GMT from United States)
If you use disk encryption, you need a backup in case something goes wrong.
(And do you encrypt the backup too? :-)
5 • Encryption (by Friar Tux on 2024-08-19 04:10:32 GMT from Canada)
I'm with @3 (Alamedated), though I don't actually fear encryption. I just find it way too cumbersome, irritating and lagging to deal with. I'm the only one using my laptop and no one else in the family even uses Linux (The Wife does, but I do the wrangling), so no one actually knows how to work our computers. I guess you could say, in our case, the very OS is the actual encryption.
By the way, in The Wife's case, one big "plus" of switching her to Linux was that her hearing aids connected automatically, directly to her laptop, which the proprietary OS never did.
6 • Encryption (by eb on 2024-08-19 07:44:26 GMT from France)
I encrypt only some files with ccrypt ; very simple and convenient. Seldom, I need to encrypt a folder : I tar.gz it, and then I ccrypt the tar.gz
7 • encryption (by dr.j on 2024-08-19 08:07:56 GMT from Bulgaria)
I use full encryption.
Anything else makes no sense in my opinion, because even in Linux systems so much data/information is stored outside the home directory that encryption is superfluous.
And fear of encryption? Unnecessary. I've been working with it for more than two decades. Back then with the good old pgp, then truecrypt and gpg etc. I now use zulucrypt. Problems: never. There is also a backup of the header - for emergencies.
8 • DIsk Encryption (by Hellfire103 on 2024-08-19 09:29:17 GMT from Belgium)
I use full disk encryption whenever possible, whether its using LUKS, FileVault, GELI, or whatever. However, this is not yet possible on my Raspberry Pi 5, so I just use encfs to encrypt my $HOME.
9 • DIsk Encryption (by James on 2024-08-19 09:33:02 GMT from United States)
I don't use DIsk Encryption as I only use one OS on any of my three laptops and I am the only user. There is only myself and my wife, so I don't have any worries about anyone snooping either.
10 • Disk encryption (by DachshundMan on 2024-08-19 10:50:44 GMT from United Kingdom)
I don't encrypt my disk or partitions but I do use Veracrypt, a successor to Trucrypt, to store some files that I want to keep secured. I chose Veracrypt as it also works on Windows and therefore I could read my encrypted virtual disk from my corporate laptop if required.
11 • Encryption (by Jesse on 2024-08-19 10:52:22 GMT from Canada)
@3: " My work computer encrypts the disk and it takes them about 15 minutes to boot up. "
Disk encryption carries almost no performance penalty. You won't notice any slow-down from using disk encryption. Something else is very _very_ wrong with your work computer.
@4: "If you use disk encryption, you need a backup in case something goes wrong."
You should have a backup whether you encrypt or not. Accidental deletion of files or hard drive failure will ruin your day just as quickly as an encrypted partition.
12 • Encryption (by Alfonse on 2024-08-19 11:00:41 GMT from Czechia)
I use LUKS for full encryption (except for /boot).
@11 Jesse, thank you, you just spared me from answering @3 and @4. :)
By the way @4: yes, my backups themselves are encrypted, and they are made to disks which in turn are also encrypted. (LUKS+borgbackup)
13 • Liya (past) (by Nathan3 on 2024-08-19 12:33:24 GMT from United States)
I tried Liya (1. something) last summer for about three months on a Dell laptop.
Clean, easy to set up and use.
I used the three CLI commands after installation, not the Pamac gui process.
I had no need to use the AUR.
This was the only Arch or Arch based distro that got through more then three updates
before getting corrupted. Others refused to advance to the login screen, refused to accept
my used name or password, refused to open the browser etc.
So, good memories of the previous version.
The Dell was / is a "play" laptop used to check out distros. This week, I tried Archcraft
(Arch + openbox), Lilidog (Debian + openbox) and presently Linux Mint 22 "MATE"
Awaiting sometime in Sept 2024 for Lilidog 2.0
My daily driver remains MX, currently version 23 XFCE but with the Cinnamon desktop
on a Lenovo desktop PC. So far (more then 4 years) no reason to change from MX
except to upgrade to the latest version.
14 • Liya (by TMoss on 2024-08-19 13:53:57 GMT from Belgium)
@13: I assume you meant that you got through more *than three updates (took me some time to make out the meaning of your sentence).
I had some problems until I refrained from updating with something else than pacman -Syu. From that point on, I've used and updated a couple of Manjaro installations for more than 2 years without any trouble.
15 • disk encryption (by penguinx86 on 2024-08-19 15:11:00 GMT from United States)
I don't encrypt anything. I have a handful of home computers and the rest of my family never uses them. They're too busy with their iPhones to bother with a computer that doesn't have a touchscreen.
16 • Missing information (by Martins on 2024-08-19 17:23:52 GMT from Portugal)
In your "Summary of expected upcoming releases" section, you forgot to mention the upcoming interim release of ubuntu 24.04.1 now rescheduled to 2024-08-29. It may be important for the many users of ubuntu, only this interim release will allow the use of "do-release-upgrade" for those who use older ubuntu releases.
17 • disk encryption (by IchWerSonst on 2024-08-19 18:16:11 GMT from Germany)
@6: Didn't know that one. Seems handy, like kryptor but with less functions.
To address the "naysayers". Encryption is really not that hard to cope with nowadays. If you're using a laptop or any other mobile device, encryption should be mandatory. No matter if you're the only one in your relationship/family using it. Think of theft/robbery i.e.
Some useful tools:
https://www.privacyguides.org/en/encryption/
@12: Same thought. :D
18 • Encryption (by Much Derper on 2024-08-19 18:20:25 GMT from United Kingdom)
@11
> Disk encryption carries almost no performance penalty. You won't notice any slow-down from using disk encryption.
That's not an absolute, it's conditional on hardware being sufficiently new to support AES-NI or an equivalent instruction set. For people that still rock, e.g., first-gen Core i7 CPUs (like the one in the otherwise still quite usable with its 32GiB RAM and SSD ThinkPad W510 I have) disk encryption does slow down the system noticeably enough. And it not only causes the disk I/O to be slower than it would be otherwise, but it also takes away CPU cycles from the rest of the software. Still, depending on the workload the system can still remain quite usable even then.
19 • Encryption (by Jesse on 2024-08-19 20:15:20 GMT from Canada)
@18: "That's not an absolute, it's conditional on hardware being sufficiently new to support AES-NI or an equivalent instruction set. For people that still rock, e.g., first-gen Core i7 CPUs (like the one in the otherwise still quite usable with its 32GiB RAM and SSD ThinkPad W510 I have) disk encryption does slow down the system noticeably enough."
First, no you don't need a newer computer/CPU to run encrypiton without a noticeable performance penalty. Second, there must be something else affecting your machine, it's not going to be the encryption.
I can run encryption on a 15 year old laptop with a spinning drive, 4GB of RAM and i3 processor in it with no performance hit. There is no way you're seeing a slow down due to encryption on anything made in the last decade or so.
20 • Use encryption (by Simon on 2024-08-19 23:11:00 GMT from New Zealand)
As long as you’re perfectly comfortable with burglars or hackers browsing through all of your data, sharing your photos, reading your emails and using them to impersonate you, and so on and so on, it can indeed make sense to avoid encryption as it can involve a very small cost (depending on your implementation) in terms of speed and/or ease of data recovery.
On the other hand if you’re not completely comfortable with the contents of your computer being fully available to anyone who wants to use them for any purpose, it would be ridiculous not to implement something so easy and with so much flexibility (you can encrypt anything from physical drives to single files… including encrypting large single files that you can then mount as drives full of directories and data).
It’s maybe possible that the 71% of poll respondents who don’t use encryption at all genuinely don’t need it… but I bet some of them are just counting foolishly on good luck. They may regret it when their laptops are lost or stolen and they suddenly realize that their login password couldn’t stop a competent 7-year-old and their digital lives are now anyone’s for the taking. Especially if they were foolish enough to allow their browsers to save their online passwords too, on unencrypted systems that allow anyone to launch those browsers as if they were the owner! Some folk seem to go through life with an irrational “it won’t happen to me” filter: it certainly does happen, so if you don’t want it to happen to you, use encryption.
21 • encryption / paranoia (by Steve on 2024-08-20 00:13:36 GMT from New Zealand)
@20 - depends on the crime rate in your part of the Great Green Lie, aka NZ Aostealaroa.
I travelled to Africa a few years back and my laptop was encrypted - just in case, to calm the fear mongerers. I returned with the laptop, the only "feature" was I had a ridiculously slower laptop and an extra step login for that period. It got reinstalled within a week of returning.
Talking of installs. Noto. Do I need to say any more to anyone in Linuxland? Everything from LinearA and Egyptian hieroglyphs, to Mayan, and 200+ Indic fonts - FORCED IN and as a DEPENDENCY by crucial packages at the unremovable CORE of many, many distros. Gentlemen (distro makers), unless you want to see BILLING for my hours to clean up this Noto s**t, drop this dependency!! I am the ba***d who WILL come knocking at your Embassy's door, bill in hand!
22 • Encryption (by ThomasAnderson on 2024-08-20 04:27:52 GMT from Australia)
Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to suffering.
Do not fear encrypting your drive, whether a full disk or just the home partition with LUKS, it is battle tested now for years without any issues.
The reasons why you should encrypt at the bare minimum your /home are primarily for privacy. We all have things we need to keep confidential and encryption is your friend in this regard.
Almost everyone has a mobile, which is encrypted. Do you fear having an encrypted phone? If not, why fear an encrypted drive which provides so much benefit. Even on Windows, installations are encrypted with Bitlocker, although not secure, encryption is there.
Embrace encryption. Edward Snowden warns that if your computer or laptop is stolen, “pictures, where you live, where you work, where your kids are, where you go to school” would all be accessible to a criminal.” Not to mention financial records, personal documents, potential passwords, crypto wallets etc etc.
23 • @22 Thomas Anderspn: (by dragonmouth on 2024-08-20 11:36:14 GMT from United States)
There is also paranoia which leads to hysteria.
If you feel the entire world is just itching to have a look at your files.and you MUST encrypt, have at it. I don't encrypt but then I do not keep my entire life on my computer. The things that I "need to keep confidential" are NOT on my PC. They are safely stored away.
BTW - your PC can be encrypted three ways from Sunday but there is NOTHING that you can do about personal and confidential information gathered by every institution you deal with. How many BILLIONS of records have been compromised by the breaches of such institutions? How would your fully encrypted PC prevent your private and confidential information being stolen?
24 • Encryption (by picamanic on 2024-08-20 11:39:06 GMT from United Kingdom)
OK, I am convinced by the need to encrypt more of my "home" directory. At present I just use a symmetric AES file encryption for files containing "secrets". The only complication of is that I use a semi-custom filesystem Mirror based on Lsyncd for my "home" directory. I might have to create some new software to realise this.
I am wary of encrypting the whole file system or even whole "disk". Just gut feeling.
25 • Encrypted Install Tips (by Random Experienced Void User on 2024-08-20 17:17:31 GMT from United States)
For pain-free setup, make /boot a cleartext partition, encrypt the rest. Nearly all of the supposed "pain" of encryption revolves around bootloader issues. So /boot should be cleartext ext4 minus journaling. Bye bye bootloader hassle. The /boot files are not your personal work or configs anyway. Leaving /boot as cleartext is a rational trade-off. Technically you could stash /boot on a separate USB key, just as you could a keyfile.
I never let installers partition disks, but use gdisk, and often make my own filesystems too. Installer options are too limited and outdated. Installers still enable swap needlessly. The best advise on /swap is not using it. And I *always* turn off ext4 journaling. That change makes ext4 faster and more stable. Installers don't present the option.
The minimum to encrypt: /root, /home, and /etc, which encompass $HOME, $XDG_CONFIG_HOME, and $XDG_DATA_HOME for all users. Yet encrypting everything is easier than such cherry-picking.
Backup is simple with ddrescue. Create an image of the encrypted partition on another drive. That image is equally encrypted and mountable as a filesystem. This method is neither space-efficient nor maximally fast, but trivial, and makes recovery so. To get an old file, mount the image and copy the file out. To restore in full, ddrescue the whole (unmounted) image back to the (unmounted) source partition. You can finish a full system backup (all partitions) in under an hour, give or take.
The world needs encryption more in communications. Distros should package the superb SimpleX Chat app which covers all platforms and phones. There's even an AppImage. The home page lags development, so get releases from GitHub. Currently 6.0.1 is the latest.
https://simplex.chat/
https://github.com/simplex-chat/simplex-chat/releases
RetroShare is another vastly underappreciated and also multi-mode comm app with solid encryption baked in.
26 • fixpacrepo (by Jacob Kauffmann on 2024-08-20 21:20:24 GMT from United States)
"Yes, I probably should have found the instructions to run fixpacrepo to rebuild the repos and update the GPG keys sooner than I did. And, almost certainly, an Arch devotee would have known to do it as matter of course."
While a well-versed Arch user might have known how to investigate the issue to fix manually, there is no such "fixpacrepo" command in Arch, as far as I can tell. I tried to look and see if it's an in-house Liya Linux tool, but I'm having a hard time finding any of Liya's source code.
27 • fixpacrepo (by Roger Brown on 2024-08-21 01:46:10 GMT from Australia)
@26 - Further to this topic, trying to find an easy entrance to Archlinux by installing a distro based on an Archlinux snapshot is invariably bad news due to the likely large number of updates and the possibility of package authentication issues.
Users unwilling to adopt the Archlinux manual install procedure should look for a "live" installer which will pull the latest packages.
I'd recommend either Arch's own archinstall script or the excellent Calam-Arch installer found on Sourceforge.
28 • @21 (by Simon on 2024-08-21 01:49:19 GMT from New Zealand)
A "ridiculously slower laptop" is not encryption's fault: that's just user error. If 95% of a drive's contents are files downloaded from distro servers and installed from packages then those are publicly available files so to waste time encrypting and decrypting them is more likely to be a mistake than a real need for that level of security. When it comes to encrypting all of home, that's more reasonable because a lot of data can be hiding in hidden directories that users don't know about... but users who are familiar with the contents of their home directories can usually encrypt a single secure folder and pop anything sensitive in there... it has zero impact on system performance.
As for the "Great Green Lie", you must be living in an unusually dangerous neighbourhood, or else perhaps basing your opinion on reporting (which, obviously, chases ratings with an endless parade of crime) rather than stats. New Zealand is consistently ranked as one of the safest and least corrupt nations in the world: the US, for example, has a much higher crime rate. Knowing how safe this country is relative to others doesn't change the fact that laptops are often stolen from public places, here as in other countries, desktops are occasionally stolen in burglaries, and everything on the Internet is an attack surface for people in much less safe nations (China, Nigeria, etc.) to get their hands on whatever they can.
It's not just a matter of personal privacy: anyone with clients and legal obligations to protect client data or commercially sensitive data and so on definitely needs encryption. I still think most of the people who said they're not using any encryption probably should be (or they are already, because they're just playing with Linux and are using encryption on their Windows or Mac boxes). But if you don't need it, cool: like I said, if you don't really need it then it makes sense not to use it, as things are simpler without it. Most people though, if they're using their computers in the real world, do need it and should be using it.
29 • Encryption (by Jason on 2024-08-21 03:49:25 GMT from Canada)
I am not against the idea of encrypting and I think businesses should definitely do it but for myself, I have a couple dozen computers at home and nothing on any of them is of any concern that I would be worried about it being lost or stolen, anything important is kept on removable media on multiple backups, and any serious internet usage(banking,payments,etc.)I do through secure anonymous browsing with nothing saved beyond that session so I just never seen the point in personal encrypting at home. So honestly in 24 years of linux usage I have never even once played with encryption, maybe I should try it out sometime just to have the experience with it if it ever comes up but I seriously have no opinion on the tools for it.
30 • disk encryption (by Vukota on 2024-08-21 13:15:32 GMT from Serbia)
@4: "And do you encrypt the backup too?"
Of course I do. That one is even more likely to get lost or stolen (or digged up from trash). For easy, full/partial and fast access to the backups and "refresh" I make raw file on external medium as LUKS encrypted disk with compression. I can even access that from Windows (and WSL) what other options doesn't provide.
31 • @11 Jesse, that does make me suspect drive failure or a bad drive connection (by RJA on 2024-08-21 13:20:48 GMT from United States)
That's likely a bad drive, indeed. Or the drive connection is bad, causing the OS to be in PIO mode! PIO mode=They will be lucky to get 5 MB/s-7 MB/s!
32 • Package Cache + Be Worried Already (by Random Experienced Void User on 2024-08-21 19:40:12 GMT from United States)
@28 @29 "...files downloaded from distro servers...are publicly available...so to waste time encrypting and decrypting them is...a mistake [not] security."
Fair point. Now carry that thought to its logical conclusion: package cache belongs in tmpfs regardless of encryption. Putting it on disk at all is bad engineering. You want performance? Then why write packages to disk at all? Keep them in RAM, where they were first downloaded anyway, use them from RAM, and delete them from RAM. They are deadweight after installation. Save disk write time and space! RAM is 100x faster and erases itself at shutdown. Most distros have an env var to set cache location. It should be tmpfs by default. All distros would boost performance and free disk space with this change.
The encryption story changes after installation. Once the package is installed and running, configuration files hold sensitive data. Even library files, with the right network hack, evil maid, or government backdoor, could be compromised. Think about replacing glibc with a backdoored version. Nobody steals your laptop. Someone just inserts a USB key and copies a file to it while you took a bathroom break at the airport. The attack comes over the Internet weeks later. Or the enemy might be your kid's school chum doing it in your own house. Your lack of encryption enabled this attack.
Official packages are threats too! Recently the humble xz compression library was caught. Heartbleed lived in the SSL lib. Online banking activity was wide open. Anyone with 5ki11z could have written JavaScript to read your disk through an "secure" website. Lately the entire US Social Security database was lifted. Ransomware is everywhere. Threats exist whether you imagine yourself living with safe people, or on safe property, or not. Assuming that you know in advance what form and fashion future attacks will take is hubris.
Businesses have this hubris in spades and are dumb as rocks. Few have security oversight officers. People don't want to bother. They want an easy-peasy, unencrypted, "paperless" work life. I once contracted with a European concern. It asked me to scan and transmit official IDs and bank statements as image attachments to e-mail. I told them that request was extremely stupid and no, I would not do it. That set of files is everything a thief needs to rob me blind. I would mail paper copies. Businesses want to go "paperless" and think it's very clever and efficient and hip. Sensitive document scans, whether sitting on disk or transmitted, need encryption.
Those afraid of OS disk encryption might want to use Tomb for sensitive files or current work. The latest Tomb is 2.11, Void is at 2.10, Debian stable at 2.9, Debian sid at 2.11.
https://dyne.org/tomb/
33 • Packages (by Jesse on 2024-08-21 20:19:21 GMT from Canada)
@32: "Now carry that thought to its logical conclusion: package cache belongs in tmpfs regardless of encryption."
This isn't a good idea as it means you can't access/use the packages later if you want them. For example, to re-install or downgrade a package. You'd need to fetch them over again, which is going to be a problem if an update broke your network connection.
"You want performance? Then why write packages to disk at all? Keep them in RAM, where they were first downloaded anyway, use them from RAM, and delete them from RAM."
This already happens automatically. Files downloaded and saved to the disk are cached in memory. It doesn't speed up anything to put the files in tmpfs because they're already cached. Writing to the disk just saves the packages for later use/querying.
"All distros would boost performance and free disk space with this change."
They'd save a few megabytes of disk space, which no one is going to notice. But there wouldn't be any performance boost due to the caching in RAM.
34 • Liya 2.0 (by zephyr on 2024-08-21 21:32:29 GMT from United States)
Installed Liya, found it to be attractive and easy to use distro. Found none of the issues Jeff Siegel mentions. Install was great, update and added extra apps with pamac. No issues what so ever and now day 3 as a daily driver. I like it.
35 • Disk encryption for laptops requiered (by Sebastien on 2024-08-21 22:07:15 GMT from France)
@9: here all laptops of the family have disk encryption activated. Because one can always be stolen, whether you bring it outside the house or not. Loosing your favorite device would be already a bad experience you would not want your sensitive data to leek as well, this would be even worst.
36 • Encryption (by Josh on 2024-08-21 23:51:20 GMT from Spain)
Encryption is the bare minimum, all phones use it in user data, an computer without encryption is basically open for anybody who plug something. The idea that anyone should just disclose everything is bonkers made by social media.
37 • Package Fallback Trope (by Random Experienced Void User on 2024-08-22 00:17:15 GMT from United States)
@33 Hi Jessie, I've run this way for years on multiple distros. I never need to fallback to some old version. It's a trope in my opinion as a software engineer. I don't know why so many devs are stuck on the idea. Maybe your personal use case as a regular distro tester is unique.
Caching in tmpfs does not happen automatically. If you mean disk cache, yes hard drives have that, and SSDs are another ball of wax. Eventually there is a physical write to physical disk media (and SSD writes are notoriously slow compared to HDD platters). If you mean RAM cache related to the file system, it's exactly the same story. Eventually a disk write (flush) happens. Only if you tell the distro to *store* packages in tmpfs will you avoid disk writes to actual media.
And unattended cache can easily eat gigabytes. The typical n00b will never clean it. I have in the past found myself shocked at the wasted space on my own systems.
Even as a software engineer who distrohops and runs Ventoy I have never, repeat never, not once, *ever* needed to fall back to an old version of *anything*. If that need occurs, the upstream distro itself reverts users to the old version via the package manager. It has happened e.g. in Void with the recent xz fiasco.
Ultimately one can carry the off Internet logic to its own conclusion too. If lack of Internet is anticipated, one should maintain a full rsync copy of the entire distro repo. You know, all 2 terabytes. After all, you never know what app you might want to install when your Internet is off. These hypotheticals get silly. In practice nobody needs a package cache on disk. It's bad engineering these days. When RAM was small things were different, and that was also when we still needed swap.
38 • File encryption (by Rothingham Coyle on 2024-08-22 05:38:12 GMT from United States)
I write my own encryption software, my own algorithms, and use it extensively to encrypt
any and all of my sensitive files. That way I know for certain that I'm not using tools that contain trap doors, have been cracked or otherwise compromised. I won't divulge my methodology but I do encourage others to use home grown encryption to secure their really sensitive data.
39 • re: File encryption (by picamanic on 2024-08-22 09:04:32 GMT from United Kingdom)
@38: Just out of interest, does your encryption software depend on being itself secret, or could you publish it?
40 • Filw encryption (by Rothingham Coyle on 2024-08-22 11:24:22 GMT from United States)
It depends heavily on being itself secret. I keep the source code locked in my safety deposit box and the executable I keep on a usb memory chip so that it only gets exposed to my operating system whenever I have to use it.
41 • @37 (by Jürgen on 2024-08-22 12:04:05 GMT from Czechia)
@37 Sorry, but you're full of fallacies *and* confidence, which makes for false statements and a terrible "community experience".
You appeal to your supposed authority, namely to your supposed experience[d user] and software engineer status. Appeal to authority is a common fallacy, yet you consistently do it, which is just all the more proof that your supposed labels mean nothing. It's also funny how you, a supposed software engineer don't know what caching Jesse was referring to, or at least you pretend not to understand it.
> I never need to [...] in my opinion as a software engineer. I don't know why [...] Maybe your personal use case as a regular distro tester is unique.
Your ignorance and faulty thought process shine here. You call out Jesse for mentioning his own use-case, while you keep referring to your use-case as if it mattered anything *in general*. It doesn't. And if it did, so did Jesse's. (Also, look up the Linux-related software Jess has or is maintaining, compare that to your "experience", and then decide who has more "authority" to make fact-based statements in these topics.)
It's also funny you try to justify your *opinion* with your recurring label ("software engineer"). No offense, but what kind of engineer does that? =)The "I don't know why" and the "maybe" also speak for themselves, you seem to have only ideas, but little relevant knowledge in the field.
> and SSD writes are notoriously slow compared to HDD platters
I must have misunderstood you, but it seems you think SSDs are slower than traditional HDDs. Is that what you meant?
> And unattended cache can easily eat gigabytes.
For which there is at least an order of magnitude more space on the hard drive than in memory. Not everyone has your fancy "software engineer" machine with zettabytes of memory, especially not people with "older hardware". Also, the RAM being much smaller than the hard-drive means the RAM will fill up much faster (with your idea of caching everything there), which just defeats the (/your) whole purpose.
> Even as a software engineer [..] I have never, repeat never, not once, *ever* needed to
Again, appeal to authority, and appeal to your own needs as if it were the needs of others or as if they proved any technical point. (They aren't and they don't.)
> Ultimately one can carry the off Internet logic
Slippery slope "argument"; apparently you still lack any real arguments.
> one should maintain a full rsync copy of the entire distro repo. You know, all 2 terabytes.
Not even close. You would need a basic set of packages, including drivers for our hardware. Most of the popular disrtibutions provide them on their live discs, and if not, you could just download them and write them to a USB key. Again, you make faulty and ridiculous statements to try and prove your point, but again, it shows your ignorance and faulty thinking.
> These hypotheticals get silly.
Your hypotheticals get silly. Also, labelling legit concerns as "hypotheticals" is not an argument.
> In practice nobody needs a package cache on disk.
"In practice" means "some (maybe many) people do, but I want you to forget that, because that would reveal I'm wrong". Also, you forgot to prove your statement.
> It's bad engineering these days.
Except when it isn't. Hard disk space is way cheaper (and therefore way more plentiful) than RAM, therefore it makes sense to use it for caching the latest version of any installed packages, because the cost is so little. With companies with their own package caches/proxies, it is almost mandatory. (Red Hat Satellite comes to mind.) By the way, while it's anecdotal, my Mint install seems to only store a single deb package in the cache right now, so I wonder how many desktop distros cahce packages these days. If not many, then your assumption about disks getting full is even less likely; if many of them, your argument about no one needing it is false. :)
Also "bad engineering" is silly coming from an "engineer" with incredulously faulty thinking, wrong assumptions, false statements, statements without proof, appealing to authority, using anecdotal "evidence" and an insufferable amount of ego. Please, less hubris, more facts, more logic. (If you won't stop making yourself look bad, please at least stop engineers look bad.)
42 • Cache (by Jesse on 2024-08-22 12:36:55 GMT from Canada)
@37: " I never need to fallback to some old version. It's a trope in my opinion as a software engineer. "
So because you don't use a feature in your job you feel it's not a feature anyone would use in any job? That seems a bit narrow in focus. I can tell you, as a system administrator, it's often handy to be able to rollback packages. Perhaps broadening your view to what other people want/need would shine light on what features make sense in a distribution.
"Maybe your personal use case as a regular distro tester is unique."
Do you think my entire career in IT for the past 25 years has just been reviewing a new distro every week?
"Caching in tmpfs does not happen automatically. If you mean disk cache, yes hard drives have that, and SSDs are another ball of wax."
I'm not talking about using tmpfs or disk cache. I'm talking about how all files the operating system accesses (downloads or reads) are kept in memory. All the files you open (or download) are kept in RAM. tmpfs for files you plan to just download and access once is redundant.
"If you mean RAM cache related to the file system, it's exactly the same story. Eventually a disk write (flush) happens. Only if you tell the distro to *store* packages in tmpfs will you avoid disk writes to actual media."
Yes, eventually the package gets written to the disk, but that's not a problem. The disk won't be the bottleneck when downloading new software and updates, the network connection will be. Also, you're going to end up writing to the disk eventually when you install the package (probably to /usr or /opt). One way or another, data is going to end up on the disk. tmpfs just adds an extra step you don't need to set up due to automatic RAM caching.
"And unattended cache can easily eat gigabytes."
Modern drives are in the range of 500GB to 8TB. You can easily update a distribution for years without ever noticing the few GB of space that might get consumed.
"Even as a software engineer who distrohops and runs Ventoy I have never, repeat never, not once, *ever* needed to fall back to an old version of *anything*."
Again, you're assuming your needs and experiences match everyone else's. But we have different jobs. Your needs are not my needs and vice versa.
"Ultimately one can carry the off Internet logic to its own conclusion too. If lack of Internet is anticipated, one should maintain a full rsync copy of the entire distro repo. You know, all 2 terabytes. After all, you never know what app you might want to install when your Internet is off."
Now you're just being silly. I pointed out it's possible to have one key package break during an update (like Network Manager) and it's handy in those cases to be able to revert from the cache immediately, instead of re-fetching the package on another machine or recovering using live media. Can you think of a better/faster way to recover than having the last version in the cache?
"These hypotheticals get silly."
Your extreme version of caching the entire repo, instead of just packages the system is actually using is certainly silly. Why would anyone cache packages that aren't installed?
"In practice nobody needs a package cache on disk"
This is factually wrong. Lots of people do. It's just _you_ don't and you don't acknowledge the use cases of others.
43 • encryption? Yes, pleas... (by tom joad on 2024-08-22 20:59:52 GMT from United States)
I am shocked.
Only 14%, as of this writing, use full disk encryption.
I spend a lot of time on the road and in public facilities. I am on the go all the time.
Several year ago i started encryping. First my laptop. Later, I encrypted my hope tower. And since then I have moved on to encryping USB drives. And I encrypt my frequent back up also. Lastly I have added encrypted cloud storage.
Sorry to disappoint you; I am really just an average Joe. But my stuff is MY stuff and I fully intend to keep it my stuff.
I find it equally shocking that 75% of the respondents don't encrypt anything. I wish them the best and maybe where they are there just isn't a need for encryption. I wish I lived there. But I live in 'realville.' In realville we have to have our dukes up. My world is full of a lot of bad actors who daily seem to be ever more intent of getting at our stuff.
And I am ever more intent on keeping those bad actors at bay.
Lastly my question to the 75% who encrypt nothing why bother with passwords, anti viruses, etc.? Why lock your doors at night or any time for that matter? Just leave the keys in the ignition too. Let folks rummage through your purse too and leave your wallet on the bar while you to go to the bathroom.
Think!!!!!
44 • nocrypt. (by Jack Byus on 2024-08-22 22:45:11 GMT from United States)
As always, the minority speak the loudest. For the rest of us 75%, we just smile and move on.
I have never nor will I ever encrypt. Simple as that. What are they going to find; an operating system, some useless text files. My important stuff is kept off-line.
45 • nocrypt two (@44) (by Kilroy the Great on 2024-08-23 02:33:57 GMT from United States)
I spent some years looking at other people's computers. The stuff people keep on their hard drives is mind-boggling. Never mind hacking or stealing passwords, I could have had a tidy blackmailing side-gig. Unfortunately, I didn't get Hunter's laptop, or I could be set for life. Of course, drive encryption would not have helped in those cases, since I needed access to the systems to do the job. File encryption, maybe. So, do I encrypt? Not really. Like @44, anything I wouldn't want my saintly mother or my enemies (if any) to see is off my computers.
Traveling with secrets? Encrypt the files if you must. Put them on the cloud. Access and decrypt at your destination. Home burglars want to sell your computer quickly, not spend time trying to find your porn. Hackers have easier and more effective ways of getting what they want. Unless you're a government or corporate minion privy to important secrets, no one really wants your stuff so badly. I've been all over the world, including some unsavory places. As the man who jumped off the Empire State building said when passing the 50th floor: So far, so good.
46 • @43 Tom Joad: (by dragonmouth on 2024-08-23 10:39:14 GMT from United States)
If we followed your reductio ad absurdum, we would all live in concrete bunkers with 2 foot thick walls and 2 inch bars on gun-slit windows, the whole bunker surrounded by razor wire and mine fields. There is caution and then there is hysteria.
47 • ZFS encryption (by Dave on 2024-08-23 13:05:53 GMT from Australia)
I use ZFS to encrypt the whole disk - well partition - gotta have uefi partition.
One reason is it's so much simpler. A file system on a partition.
As opposed to a disk, with partitions, with lvm, with luks, with a file system all stacked on top of each other 🫤
48 • @47 - thanks for the reminder (by Brad on 2024-08-26 00:13:38 GMT from United States)
Late to the party, I know -
Based on the ZFS recommendation above, I decided to re-visit an old friend - NomadBSD.
It worked even better than the last time I tried it, and it is now residing on my "play" laptop. I've been learning how to use ZFS, and it's been a revelation. I may be a noob, but it seems as though ZFS encryption may be the solution that some folks seek for keeping their data secure.
UNIX was actually my first "serious" OS (4.2 BSD, back in the days of ARPAnet), and I'm starting to see its advantages over Linux-of-the-day.
BSD's actually work on my laptop with wireless out-of-the-box now! There are still issues with incorrect or sparse documentation for the "derivatives", but the FreeBSD handbook has saved me more than once today. This may become my daily driver soon.
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 | 
DragonFly BSD
DragonFly is an operating system and environment designed to be the logical continuation of the FreeBSD-4.x OS series. These operating systems belong in the same class as Linux in that they are based on UNIX ideals and APIs. DragonFly is a fork in the path, so to speak, giving the BSD base an opportunity to grow in an entirely new direction from the one taken in the FreeBSD-5 series.
Status: Active
|
| TUXEDO |
TUXEDO Computers - Linux Hardware in a tailor made suite
Choose from a wide range of laptops and PCs in various sizes and shapes at TUXEDOComputers.com. Every machine comes pre-installed and ready-to-run with Linux. Full 24 months of warranty and lifetime support included!
Learn more about our full service package and all benefits from buying at TUXEDO.
|
| Star Labs |
Star Labs - Laptops built for Linux.
View our range including the highly anticipated StarFighter. Available with coreboot open-source firmware and a choice of Ubuntu, elementary, Manjaro and more. Visit Star Labs for information, to buy and get support.
|
|
• 
• 
• 
• 
• 
• 
• 
