 DistroWatch Weekly |
| 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$9.56) |
|
|
|
 bc1qxes3k2wq3uqzr074tkwwjmwfe63z70gwzfu4lx  lnurl1dp68gurn8ghj7ampd3kx2ar0veekzar0wd5xjtnrdakj7tnhv4kxctttdehhwm30d3h82unvwqhhxarpw3jkc7tzw4ex6cfexyfua2nr  86fA3qPTeQtNb2k1vLwEQaAp3XxkvvvXt69gSG5LGunXXikK9koPWZaRQgfFPBPWhMgXjPjccy9LA9xRFchPWQAnPvxh5Le paypal.me/distrowatchweekly • patreon.com/distrowatch |
|
| Extended Lifecycle Support by TuxCare |
|
|
| Reader Comments • Jump to last comment |
1 • Portable Packages (by John on 2021-10-04 00:40:32 GMT from Greenland)
Interesting points by Drew DeVault. I also prefer distro specific files vs Snap / Flatpak etc...
2 • Packages + Ansible (by Wedge009 on 2021-10-04 01:10:01 GMT from Australia)
John and I seem to be among a shrinking minority that prefer distribution packages over Flatpak/Snap distributions. As someone who's been using Linux for a while, but only started using it full-time on my primary machine since January 2020, portable packages feel an awful lot like the stand-alone application installations commonplace in Windows (at least before version 10). I understand there are some advantages to that, but disadvantages too.
On the topic of multi-machine management, I don't use any for my home computers, but I've used Ansible a bit for my work. I'm far from an expert, however, though I've found it useful in some situations.
3 • Distribution Packages (by cpoakes on 2021-10-04 01:33:06 GMT from United States)
I also prefer native packages from my distribution and avoid distros that incorporate heavy use of Flatpack/Snap packages.
SUGGESTION: Give us a survey that reflects how users employ native vs Flatpak/Snap packaging.
4 • Packages (by Charlie on 2021-10-04 01:52:26 GMT from Hong Kong)
DeVault's view is correct in a certain point, esp in the view of sysadmin. But it doesn't work for ordinary users. Many are already familiar with downloading packages themselves in other platforms.
Things however may turn around as under mobile platforms the concept of app center becomes popular, if the traditional way of software distribution continues, what distro/DEdevelopers should do is to polishing the app center and makes it really useful. Right now I can't find one suits this criteria, either too complicated (YaST software center) or too simple (KDE Discover, GNOME software).
5 • A case against portable packages (by Tech in San Diego on 2021-10-04 01:56:26 GMT from United States)
Jessie wrote a recent opinion poll which showed that many of us still prefer distribution packages over running AppImage, Flatpak, or Snaps. (see DistroWatch Weekly, Issue 926, 19 July 2021) https://distrowatch.com/weekly.php?issue=20210719
In my opinion it's a solution looking for a problem, but don't tell that to Canonical.
All the Best!
Tech in San Diego
6 • Packages (by Ken on 2021-10-04 04:07:03 GMT from United States)
I'm with DeVault. The common way of distributing packages in the GNU/Linux ecosystem addresses the very problems with portable packages that drove me away from Windows. Distros going the route of replacing all traditionally packaged software with portable packages will just end up with the same problems.
7 • @ Ansible: say I have 1000 machines... (by nooneatall on 2021-10-04 04:38:20 GMT from United States)
This is just curiosity, but seems a key point not mentioned.
The IP addresses and passwords of machines on your network are listed somewhere on your Root Of Roots, right? Is there a tool other than text editor to import those properly formatted as "10.0.2.15 ansible_ssh_user=root ansible_ssh_pass=rockyone" into the Ansible "hosts" file? -- Otherwise, that's a heap of editing! Done incrementally over long time, it'd be bearable, but starting from scratch with a big network, does anyone ever do that?
8 • non-repository packages vs repository packages (by Romane on 2021-10-04 05:01:01 GMT from Australia)
I much prefer packages native to my distro.
That said, if "something" I consider I need is not in the distro's repositories, I will look first at flatpak (cannot seem to get snap's to work) and then at appimage. So far I have only needed one from flatpack, which I use for many hours each day, and one appimage which is used for a very-occasional specific need.
Romane
9 • A case against portable packages (by 2103markus on 2021-10-04 06:58:28 GMT from Luxembourg)
I'm using Linux for quite a while for my private and machines and some friends who i convinced to run Linux. Therefore i use a lot of various virtual machines to test current images of debian & arch based distro's and for fun also opensuse, solus & mageia. To have the same software version on each machine i tried intensively app-images, flat-packs and snaps across various machines and distro's. It never runs well (stable and performance) on every machine and at least the packages in the repositories where the most stable and reliable ones.
10 • Distribution packages (by Roy Davies on 2021-10-04 08:03:01 GMT from United Kingdom)
Native distribution packages every time.
I trust that the distribution developer knows what works best with their distro.
11 • Portable packages (by Mike on 2021-10-04 08:58:50 GMT from United Kingdom)
Canonical are going to force people into using snap soon via transitional packages. Apparently they have an agreement with Mozilla Foundation now which dictates Firefox and Thunderbird will become a snap package only moving forwards.
It will be done soon without user knowledge via a near empty transition deb containing just a script to replace the traditional Firefox and Thunderbird packages with snaps.
Linux Mint developers already started packaging some additional stuff they used to take from Ubuntu software repositories last year if I recall right (it may have been 2019) because of these sneaky redirects and apparent package abandonment like Chromium being left without updates for months.
Having tried Thunderbird as a snap on Zorin, I wasn't impressed. It was impossible to grant it permissions to print from either the Zorin Software application which had a permissions dialogue for each package or the command line. I really hope that has changed since...
12 • Portable packages (by DachshundMan on 2021-10-04 09:19:51 GMT from United Kingdom)
I do not like portable packages, in part because the security worries me and also due to the bloat. However, I can understand why packaging less used software would not be a priority for the packagers of a distro and that the SW developers do not want to make packages for all the different Linux distros. This is where portable packages come in so I think they have their uses but I do agree with @10 that the distro developers would make the best packages for use with their distro. As a result I think that portable packaging things like Chromium that are widely used is not on but for something not used by the majority it is OK.
Having said all that I do use some Docker machines which in some way I equate with portable packages.
13 • @7 dynamic inventories in Ansible (by Andy on 2021-10-04 09:40:47 GMT from Hungary)
I believe a dynamic inventory is what you would need. (See https://docs.ansible.com/ansible/latest/user_guide/intro_dynamic_inventory.html ) I'M not exactly sure about the password management; but if you have the password manage that can be accessed from the command line, it may make things easier to programmatically retrieve the passwords. Otherwise, I'm afraid it's even more manual work to set up an inventory with passwords. On that note, I do believe the difficulty of securely managing and using passwords is one reason why such automation systems are often better off with using SSH keys to log in to managed hosts. (E.g. create a separate ansible user on managed hosts, allow it to log in with SSH key, but only from the control node[s], and make sure access to the control node and the SSH key is well regulated and logged etc. It takes some time to create such a system, but it's still easier and likely more secure than using and storing passwords for different hosts and users.)
Oh, and before I forget: Ansible uses Ansible Vault for securely storing passwords and other sensitive data.
14 • Packages, schmakages! (by Mark B on 2021-10-04 10:11:51 GMT from United Kingdom)
It’s no surprise that the unanimous view is that native packages are preferred. The introduction of Flatpaks, Snaps and AppImages serves mainly to compound an already excessive number of package formats. To me, the ideal solution is a single, universal format but the cynic in me knows that will never happen.
I think that some sections of the open-source community are causing a move away from the use of their own software on Linux and forcing people back to Windows. Let me use Audacity as a case in point. Not only was there a huge furore over the alleged spyware/telemetry (call it what you will) but the recent ‘concession’ to Linux users is an AppImage rather than a native package. By their own admission, the Audacity team released the software knowing that anything needing the ffmpeg library wouldn’t work. Why? I tried a fork of Audacity with the telemetry removed and they’d made the same call on a non-working ffmpeg. Crazy!
The alternative is the long-standing ‘compile the source yourself’ stance. I wish developers would get it into their heads that many Linux users are NOT coders or technical users. We don’t want complicated scripts or compilation instructions we don’t understand, we want working, stable, up-to-date binary packages. Sadly, I feel there is a very potent combination of elitism and ‘the curse of knowledge’ that pervades the open-source community. These attitudes exclude people. “You are not clever enough to be one of us, hard luck!” Why would I make do with an old version of Audacity when I can download the latest version for Windows and have it work fine? I’m lucky I have the choice of dual-booting.
I stopped using the excellent ebook software Sigil for the same reason. The developers stress it works on Linux but steadfastly refuse to create binary versions to do just that. Instead I bought Jutoh, written by the co-creator of wxWidgets, and provided in numerous package formats for Windows, Mac and Linux in both 32-bit and 64-bit versions. He’s a one-man organisation and he can manage it but, it seems, Audacity and Sigil (and many others) cannot. Why go to all the trouble of writing really good software and then make it tough for people to use? “Go big, or go home!”
It’s no surprise that the unanimous view is that native packages are preferred. The introduction of Flatpaks, Snaps and AppImages serves mainly to compound an already excessive number of package formats. To me, the ideal solution is a single, universal format but the cynic in me knows that will never happen.
I think that some sections of the open-source community are causing a move away from the use of their own software on Linux and forcing people back to Windows. Let me use Audacity as a case in point. Not only was there a huge furore over the alleged spyware/telemetry (call it what you will) but the recent ‘concession’ to Linux users is an AppImage rather than a native package. By their own admission, the Audacity team released the software knowing that anything needing the ffmpeg library wouldn’t work. Why? I tried a fork of Audacity with the telemetry removed and they’d made the same call on a non-working ffmpeg. Crazy!
The alternative is the long-standing ‘compile the source yourself’ stance. I wish developers would get it into their heads that many Linux users are NOT coders or technical users. We don’t want complicated scripts or compilation instructions we don’t understand, we want working, stable, up-to-date binary packages. Sadly, I feel there is a very potent combination of elitism and ‘the curse of knowledge’ that pervades the open-source community. These attitudes exclude people. “You are not clever enough to be one of us, hard luck!” Why would I make do with an old version of Audacity when I can download the latest version for Windows and have it work fine? I’m lucky I have the choice of dual-booting.
I stopped using the excellent ebook software Sigil for the same reason. The developers stress it works on Linux but steadfastly refuse to create binary versions to do just that. Instead I bought Jutoh, written by the co-creator of wxWidgets, and provided in numerous package formats for Windows, Mac and Linux in both 32-bit and 64-bit versions. He’s a one-man organisation and he can manage it but, it seems, Audacity and Sigil (and many others) cannot. Why go to all the trouble of writing really good software and then make it tough for people to use? “Go big, or go home!”
15 • @14 (by Ostro on 2021-10-04 11:23:30 GMT from Poland)
AppImages are not recent to Linux, but came 17 years ago.
16 • AppImages (by Mark B on 2021-10-04 11:27:06 GMT from United Kingdom)
@15 - Thanks I didn't know that but they seem to have only become prominent recently, haven't they? I was only meaning recent in the sense that it is new to Audacity. I hope that makes sense.
17 • Packages (by James on 2021-10-04 11:30:27 GMT from United States)
I also perfer native packages. It seems ro me developers perfer portable packages more than users.It
also seems we are destined to get them whether we want them or not.
18 • @16 (by Ostro on 2021-10-04 12:30:07 GMT from Poland)
Audacity as an AppImage was there more than a decade ago. You can learn about it here, https://docs.appimage.org/ Atm, AppImages are the only one-file portable apps around. Others, such as flatpaks and snaps need a special application installed in your system. With an AppImage, you just make it executable and click on it. You can carry them in your USB stick, or any other portable device. Runs in any distro.
19 • packages and wayland (by crayola eater on 2021-10-04 12:31:01 GMT from United States)
Against packages - bloat is the biggest con. Yes, we have wicked amounts of storage, but is that reason to have 10, 15, 20 copies of the same file/dependency. Just like the houses we live in, we have no problem filling the space without having all those extra duplicates. Not to mention the concerns made by Drew.
Against Wayland - the KISS principle of Linux seems to be lost here to me. Each desktop will essentailly have it's own 'Wayland'? - so should we expect conflicts when we boot different desktops on the same install? The reasons why mentioned above - "want a consistent look for their desktop, performance over flexibility, and security is a bigger concern" - in my mind only the last one is any possible reason to can X. Yet according to Jesse's blog, Wayland "will hopefully be more secure and offer better (and smoother) performance" makes it sound as if out of the box the pros are basically meaningless. Anyhow, 'performance over flexibility' is not a pro to start with; I mean we have such super fast CPUs and oodles of memory, faster busses, etc, so what does this performance enhancement mean to the common user - zilch? (Just like systemd's faster boot - saves you 20 seconds to boot up - and, what did you do with that 20 seconds that makes a real difference.) The same performance 'boost' with Wayland will also be just about bragging rights I guess.
And now the programers will have to re-write any packages that rely on an X feature, and de-bug that across all those different Wayland implementations? Or have to create 2 packages to satisfy both X and Wayland, or will this also be a loss of the freedom of choice that is a core feature of our using Linux in the first place.
Is Wayland as 'network transparent' as X? If not, will we be able to navigate through the increasing 'cloud computing' wet dream of our big corporation overlords?
Well, that's my curmudgeon quota reached - sorry if I went over my 10,000 steps.
20 • what the pack? (by fonz on 2021-10-04 12:33:49 GMT from Indonesia)
yeah most people would prefer native packages, having alternatives is nice unless its forced on us *cough*buntu*cough*. if only the big guys shown some more light on appimages (grats on your sweet 17, TIL ;P), they truly are the only portable packages not requiring anything else (most of the time).
multi machine management (MMM) tools sounds fun and looks like its much easier than LTSPs, my kids are happily on their rasps. i honestly dont want to RTFM to setup LTSPs again, and youre never too old to learn things...
21 • Packages (by Pat Menendez on 2021-10-04 12:39:41 GMT from Canada)
To me it is hard to disagree with the concept of native packages are the best option. Unfortunately, this is where "based on; independent" really fails perhaps the majority of end users. There is essentially nothing in the native repositories. For a lot of users who only use their computer for browsing the internet and social media that may be fine. If there are certain more obscure programs that you use a lot either you can't use that distro or you find a distro agnostic package. I find that Debian doesn't have as rich of software offerings as Arch or Mandrake (PcLinuxOS / Mageia) and it goes downhill with the forks, especially if it built on Stable. The programs I use regularly are just not there. That necessitates either going to something other than a Debian based distro or finding a Flatpack version IF the distro supports Flatpack. I'm just not understanding why Debian can't publish an easily accessed repository like Arch's AUR. With Arch or PCLOS I have never had the need to find a "Flatpack" program in order to be able to use those distros. There are many independent distros I've tried and liked but the programs I needed to be my daily runner simple weren't available. That makes distro agnostic packages almost a "necessary evil". Even then, for my daily runner where stability and reliability matter, I choose a distro that has the programs I need in their native repositories.
22 • Very nice main article (by Daniel on 2021-10-04 13:29:55 GMT from Brazil)
Guys, congratulations for the article - it is great to have a week to discuss some software that provides key features instead of yet-another-distro-review every week. Wish we could get this type of main article more often. Have a great week!
23 • Portable?? (by Friar Tux on 2021-10-04 14:00:51 GMT from Canada)
As with most of the commenters, here, I'm for native packages. I HAVE tried Snaps, Flatpaks, and AppImages, to be fair, and of the three, I found AppImages to be superior - possibly because they've been around longer and had more time to iron out the wrinkles. Also, AppImages seem to take on the themes I run on my desktop, where Snaps and Flatpak seem to use... whatever. Yes, that actually IS important to me. My eyes aren't what they used to be so a white background is like staring at a 60 watt lightbulb. It is quite shocking when you use a dark theme and suddenly your Snap or Flatpak app lights up the neighbourhood with its bright white background.
Over the years, I developed a, sort of, practise that I follow when it comes to installing a needed, new app. First, I go to the repository. If I don't find what I need there, I look for a *.deb file (that's why I like Debian and/or derivatives). If I still can't find it, I check out AppImages. So far, I've been able to get whatever I need.
As for Arch and AUR... I'll leave that to the techie group. Arch and derivatives have never played nice on any of my machines. Most break after every second or third update, so you spend more time trying to keep your system going than getting stuff done. This is also true (for me) with anything that uses YaST. It simple will not work for me. While the distro may work nicely, YaST dies every time I try to install a needed app from the Software Manager.
So far, the only actual STABLE distros I have found are Debian, and derivatives, using *GASP* systemD. Yeah, I know, shocking, isn't it.
Anyway, gotta go, The Wife wants the storm windows on for the winter.
24 • Ansible (by Luke on 2021-10-04 14:18:27 GMT from United States)
Ansible is awesome. I learned about it at a python conference several years ago and introduced it to our team at work at my previous job, and we started using it heavily, even taking over some of what used to be IT's responsibility in terms of dependencies. It cut our installation/maintenance time down by probably 90%, and it was also useful for all kinds of troubleshooting tasks.
This was back before Red Hat acquired them, and Tower only came out after we'd be using it for awhile. Interestingly enough I had written my own web interface for a couple tools. Nowhere near as complete obviously but it was good fun. Not sure how it's changed in the last couple years since I used it, though.
25 • The case for Portable Packages (by Sitwon on 2021-10-04 14:42:33 GMT from United States)
It's no surprise to me that nearly everyone prefers native packages.You should! For all the reasons Drew DeVault suggested and more.
I have been a package maintainer for several distros (including a couple special purpose distros that I helped create), so I know first-hand the time, care, and work that's involved in repackaging software for end-users.
But certain software is a pain for maintainers to deal with. When you're dealing with packages with time-consuming compiles, deep dependency trees, and tricky options and interactions between those dependencies... it can be a lot.
Multimedia-related packages in particular are a top offender, especially editing tools. Web browsers are another example.
And honestly, sometimes the just isn't that much value to the end-user in having a bespoke, custom-compiled version.
As a software developer, I also know the challenge it creates for the upstream authors when a dozen different distros are offering a two dozen different unique and customized builds against different dependencies which themselves might have been patched. Users will report issues that nobody on the development team can reproduce in their environments and it can waste a lot of time trying to track down the root cause.
Also, I sit pretty firmly in the camp that telemetry that a user can opt-out of is NOT spyware. Honestly, if you think a project is putting spyware into their code, then don't use their code. It would be pretty futile to rely on your package maintainers to be able to root it all out. In fact, the package maintainer themselves is in a position to put malware INTO your packages that doesn't exist upstream (whether intentionally or not).
For some software, distro-packaging makes sense. Specifically, for the critical software that makes up the base of the distribution and the specific, curated set of packages that make up the core user experience and directly support the distros intended purpose.
Everything else is a distraction, and portable packages can be a better option.
With portable packages you're getting the most recent release from the upstream developers (no packaging lag time, which can sometimes be years), bundled together with the exact versions of the dependencies that the developers have tested against, and you know it's free from downstream supply-chain attacks at the packaging layer.
It's not just desktop software that is trending towards this model of portable packages. Container systems like Docker are just portable packages for servers. And anyone who has worked in that world knows how that for as complicated as it can be to work with Containers, it's blissful in comparison to the old way of managing and configuring server software. Just try setting up Sendmail or Postfix from source if you'd like to remind yourself of why containers are better.
For a lot of applications these days, my order of preference is: official distro-specific package > official portable package > nix-pkg > native distro package > official generic package (these are the ones where a single DEB or RPM targets any distro that happens to use that package format, these are the ones that tend to dump stuff in /opt as Drew DeVault complains about, ironically portable package don't generally touch /opt at all)
26 • Ansible & portable packages (by Robert on 2021-10-04 15:59:02 GMT from United States)
Not much use for Ansible or similar solutions for an end-user desktop, but I have been wanting to learn Ansible or Puppet. I will have to take another look at this tutorial another time.
For portable packages, I think users are the wrong audience to try to justify their existence. Yes there are advantages, but also drawbacks. These have been well explored at this point.
Really the tech should be targeted at devs and distro maintainers. The more consistent environment should be attractive to devs, especially binary only applications like games (though Valve is doing something similar but different with their runtime). For packagers, it can lighten the load by centralizing the effort, reducing the need to package EVERYTHING, especially large and complex software.
27 • tools (by mircea on 2021-10-04 16:11:28 GMT from Moldova)
i use a combination of cfengine + hashicorp packer terraform & vault.
mainly cause all existing tools are written on python or ruby, which is nuts...
and imply to use ruby or python or yaml for scripting which is a big waste of time to learn.
28 • opt-out snap (by vern on 2021-10-04 17:27:31 GMT from United States)
I like the fact that I can dump Firefox into /opt and create a .desktop to start it. I wont be using Snap anything. Unsure about Flatpak. I have a couple of Appimages; Slick.
29 • distro package alternatives (by Happy Fun Dino on 2021-10-04 18:36:21 GMT from Switzerland)
Like many (perhaps most?) old-Linux users, I see a proliferation of proprietary packaging formats as a potential misstep.
Yes, I can live with AppImage if I truly *must* have something that isn't distro-specific - but I'd much rather compile a package from sources than deal with snaps, flatpacks, or AppImages.
People that come up with their own way of doing things (especially corporate ones) need to remember "my machine(s), my rules" applies to them too.
One size does *not* fit all; one dino's jacuzzi is another dino's tar pit.
30 • Q4OS KDE Debian 11 (by 1-DOT.com on 2021-10-04 18:42:34 GMT from United States)
Q40S has been around a long time. However, I never had any interest in Q4OS due to their prior fixation with Trinity/KDE-3. But now running KDE 5 and Debian 11, I thought that I should at least take a look.
I am impressed enough to consider replacing MX 19.4 for daily use on my 10 year old Lenovo notebook. In real world use, the new Q4OS simply feels right. I should note that I have slowly started to prefer KDE even though I disliked and removed MX KDE - not up to expected MX19.4 XFCE standards.
Other Linux partitions on this old notebook include Zorin 16 (most reliable), Feren OS (KDE), and Pop OS. I tested Elementary 6 (terrible first impression), Solus KDE (good but finicky), KDE Neon (okay but ...?) and a few other distros. I will probably next try Manjaro Deepin and Manjaro Cutefish as they mature for a bit longer.
31 • Native packages (by Dave on 2021-10-04 21:06:00 GMT from Australia)
I prefer native packages where possible. Someone else wrote we should have a single universal package manager/packages, and they're absolutely correct.
As it is with the universal packages, we have at least 3, so the fragmentation is still there.
I use Arch and am happy with their prettly large repo of software. I refuse to use AUR, in my opinion AUR is what causes Arch to break. If a native package doesn't exist, I'll use Flatpak. If that doesn't exist I'll use a nix package.
32 • Packages (by Justin on 2021-10-04 21:33:46 GMT from United States)
Having a distribution repository of curated packages was a primary reason _for_ Linux. Downloading random installers for Windows was just out of hand. At best I could hope for a no-install zip file that didn't pollute my OS, but even then, all the security stuff comes up because no one updates those DLLs. Linux solved all of this for me, and I'm grateful to maintainers that do the job well.
The "compile it yourself" argument is BS. I've been successful sometimes, but other times the developer has a "golden machine" and doesn't know it. I tried to compile a program recently following their instructions, and it just failed to compile. I never got to the step where I could make a change I wanted. As a package maintainer, this must be worse. Unless the package is quite popular, why would I waste my time? If it's easy and always works, sure, maybe, but their own step-by-step instructions fail? It's the upstream dependency's fault? Well, pick a different dependency, don't blame the maintainer or the user trying to make it work. I'm happy that so much open source software exists for so many things. However, like with everything, less qualified people produce things and don't care. At least you're not paying money for it like M$, but it's not less of a problem because you can read and "theoretically" compile the software yourself.
To be fair, sometimes the reverse is true. It can be a PITA to get anything packaged for Debian especially depending on the temperament of the maintainer. I see the argument for a portable package. Instead of all that, just statically compile everything. It's like getting an AppImage except the developer can make the whole thing themselves. And it comes with all the same vulnerabilities as other bundled dependencies that don't get updated! :) You don't need a "framework" to run an application (this is like .NET for Linux), just make a big binary blob. KISS
33 • Another ssh-based alternative (by Scott Dowdle on 2021-10-04 21:34:37 GMT from United States)
I generally use Ansible... but another tool I use sometimes for multi-machine-at-the-same-time access over ssh is.. tmux... using the "set synchronizepanes on" setting. It can be turned on and off at will as needed.
34 • Ansible and other computer management tools (by Jack on 2021-10-04 23:21:23 GMT from Australia)
My choice for an automation tool is salt. I used puppet for a while but find working with salt a lot more pleasant.
35 • Packaging formats, Wayland (by Corbin Rune on 2021-10-05 00:55:51 GMT from United States)
Honestly, that's why I stick in the Arch/Arch derivative camp. If it isn't in base repos, I look for a recently maintained AUR option. If that fails, I'll either compile from a tar, or Flatpak it. There aren't many times I've needed to go as far as Flatpak.
Haven't messed with Appimage or Snap, tbh.
As for the Wayland bit, I do find it odd that there are so many implementations, but I kinda expect it, being that it's an open-source project. And, frankly XOrg has been around for quite some time, so I get why folk seek a replacement.
36 • Portable packages (by Dave S on 2021-10-05 03:53:41 GMT from United States)
I tend to use programs from my distro’s repositories and if I cannot find something (usually something I need for work), I look in this order: Nix package manager (still trying to get the feel of Guix), Appimages, Flatpaks, and then Snaps if I must. For some things like Teams (yuck!) they are an unfortunately necessary evil.
37 • Packages (by anon on 2021-10-05 05:24:54 GMT from United States)
I always go with my distro's respository, and if something that I want isn't in the repo, then I simply compile it myself. It's the approach that I've always used when working with Linux and *BSD. I've never felt the need to try and force the Windows way of doing things on everybody whether they wanted it or not. It's really not that difficult to compile your own software. Tedious at times, but surprisingly not that difficult.
38 • Native Packages for Me (by penguinx86 on 2021-10-05 10:05:37 GMT from United States)
I really hate the way all the Snaps show up in Ubuntu when I type the 'df' command. According to the man page, df is supposed to 'report file system disk space usage'. Why do I have to see a bunch of running processes instead of disk space usage? This is totally lame. Between this and Gnome 3, I've given up on Ubuntu for good!
39 • 29 • distro package alternatives (by jJames on 2021-10-05 10:56:11 GMT from United States)
"but I'd much rather compile a package from sources than deal with snaps, flatpacks, or AppImages.'
Great for you, but it will never be the case for those that want widespread adoption of the LInux desktop. New users and those coming from other operating systems are not going to be compiiling from source to install software. This attitude iis where Linux gets it's "computer geek" reputation.
40 • Re: Sigil (by Ken on 2021-10-05 13:54:53 GMT from United States)
@14 Sigil doesn't offer an official GNU/Linux binary download themselves, but Sigil is at least packaged and available in the Debian, Ubuntu, Fedora, and Arch repos (I didn't check any others).
41 • tracking down issues (by Otis on 2021-10-05 14:06:44 GMT from United States)
@25 that whole post is quite informative and lends insight as to what's woven through the Linux world with regard to user anxieties often expressed in distro help forums. This remark says a lot to us:
"As a software developer, I also know the challenge it creates for the upstream authors when a dozen different distros are offering a two dozen different unique and customized builds against different dependencies which themselves might have been patched. Users will report issues that nobody on the development team can reproduce in their environments and it can waste a lot of time trying to track down the root cause."
We go into those forums thinking we have what must be a very common problem with this or that application on our "common" hardware in our "common" environment, and we wonder why it takes page after page of input and requests for more output from our logs. That, what you said there, and more in that post @25, explain some of the roots of the problems very well.
42 • Packages (by Moat on 2021-10-05 17:38:31 GMT from United States)
This, @26; "For portable packages, I think users are the wrong audience to try to justify their existence."
This is the *exact* reason - and "elitist" attitude, frankly - behind why portable packages are (and will remain) inferior to system-native packages; disregard of users' opinion. If it wasn't for the needs/wants of "users", software products would not even *exist* in the first place (nor would computers, for that matter). Think about it - think about @26's above statement, and its context.
Imagine a product - say, an automobile, for example - who's primary design criteria was dictated by the needs/wants of the designers, engineers and assembly workers - and not those of the customers. Who knows if it would even resemble any kind of usable transportation device... but, boy oh boy - it sure was easy to design, went together real fast (glue and pop-rivets!), and was darn cheap to produce!! Likely a POS product that would quickly fail in the marketplace.
With automobiles, at least we have choice to buy something else, something better. Linux? That "choice" that's so often touted as a clear advantage to its use, seems to be disappearing for us end-users. Another nail in the "Year of the Linux Desktop!" coffin.
The bigger issue IMHO seems to be the inherent fragmentation of the FOSS ecosystem and its constant, relentless disruption to the massive, delicate tangle (tango?) of underlying system libraries/dependencies - i.e.; constantly breaking things, even within a well-maintained distribution. Fix *that*, and all of these other issues would simply cease to exist (as well as free up an enormous amount of development resources to more important [i.e.; fun] ambitions).
But, no - as time passes, things only become more and more fragmented, it seems. No rules, no stability. Constantly fixing what didn't need fixing, re-inventing the wheel. Disheartening! :(
43 • @32 @ 42 portable packages (by Ostro on 2021-10-05 19:18:22 GMT from Poland)
If you are using a web browser to read this DW comments column, you should know that the web browser is a self-contained package sitting in a folder some place in your distro. For example, take Firefox. The whole thing with all the dependencies needed for it to run sits in /usr/lib/firefox in Debian/Ubuntu, in /usr/lib64/firefox in Fedora etc. (In Windows it sits in Program Files / Mozilla Firefox.) You can copy paste the whole folder anywhere you like and click on the firefox executive file, the web browser would start. It doesn't matter, where the folder sits, in what distro or Windows, that folder contains all the files, folders it needs. You can look at Gimp, LibreOffice and any other application.
They sit somewhere, some in /opt, some in /usr/lib, or /usr/lib64, some are in /usr/lib/x86_64-linux-gnu, most times fully self-contained. Sure, most other apps are fragmented all over the root directory, but most of the newer apps are published as self-contained and can be copied and pasted any place you want to run them.
44 • Lockboxer (by snarly Rex on 2021-10-05 23:01:15 GMT from Canada)
Lockbox Linux is making some strange claims:
* 3.4GB ISO => yet, "image has been stripped to bare necessities thus making it lightweight and seemingly fast"
* Has the basic gufw => yet, "It includes ... a highly restrictive firewall setup"
* has 15 apps / packages => yet, "OS Specifications: 8GB RAM"
This raises the question of what type of distro is most secure for your data:
* forenzic / pentesting distro
* security / privacy / anonymity distro
* cryptocurrency / trading / banking distro
* cut-down browsing / kiosk distro
-- big hug for fellow distro dinos
45 • Bashing of file system isn't cool (by Dxvid on 2021-10-06 15:21:41 GMT from Sweden)
Spreading misinformed rumors and bashing of open source filesystems or other open source software isn't cool and doesn't benefit the open source community in any way. I think distrowatch should stop bashing BTRFS for no good reason, the RAID 5/6 functionality is clearly marked with orange and red colours and it's not any hidden secret that arstechnica needs to read about in forums and report as something suspicious that proves their prejudice. It's open information that everyone can read for themselves. Any sysadmin could go to the site and see what is marked green or not:
https://btrfs.wiki.kernel.org/index.php/Status
If you need to use the slow and fragile RAID 5 or the slow and sligthly less fragile RAID 6 for some reason just use another file system or use a RAID controller, it's as easy as that. No need to talk badly about open source projects on distrowatch. Feel free to use whatever file system or software RAID you feel will be a better match for RAID 5 or RAID 6 if you don't want to invest in a RAID controller.
However a RAID controller card with some extra memory is probably a good investment and it takes away the need to use built in RAID 5/6 in file systems or in motherboards.
46 • @42 Packages (by Robert on 2021-10-06 18:13:40 GMT from United States)
@42
"The bigger issue IMHO seems to be the inherent fragmentation of the FOSS ecosystem and its constant, relentless disruption to the massive, delicate tangle (tango?) of underlying system libraries/dependencies - i.e.; constantly breaking things, even within a well-maintained distribution. Fix *that*, and all of these other issues would simply cease to exist (as well as free up an enormous amount of development resources to more important [i.e.; fun] ambitions)."
I don't disagree here. If you think you can convince the business interests, distro communities, and even users to collapse down to, say, 3-5 distros, be my guest.
IMO that ship has long sailed. Given that, and my belief that the endless repackaging of apps for a thousand different distros is unsustainable, portable packages are the only remaining solution. Now if we could just settle on ONE format, that'd be great.
This isn't mainly about the users, it's about greatly simplifying things for everyone else.
"The customer is always right" - said nobody who has ever dealt with customers.
47 • Keep them coming please (by CS on 2021-10-07 02:41:29 GMT from United States)
Haven't visited DW in many weeks, was glad that the story of the week was a utility rather than "yet another pointless distro". Hope this is the start of a trend.
48 • The year of Linux on the desktop. (by R. Cain on 2021-10-07 02:45:51 GMT from United States)
It is literally amazing how many times the words
fragmented,
fragmentation,
disruption,
regressions,
(and derivatives and synonyms thereof)...
show up in the above comments, along with somewhat disturbing (as far as 'ease-of-use' goes) statements about 'compiling from source' in order to get desired---but not delivered, nor immediately available---functionality.
This was a very good topic from the standpoint of---inadvertently---starting this type discussion. And, furthermore, the comments here represent, I think, a very good representation of the feelings of a high percentage of the much larger community of Linux users.
The comments here are, for the most part, 'spot on', and, because of them, result in two comments from me which are **strictly my opinion**; I would like nothing more than dissenting opinions---
1) There will never be a "Year of Linux on the Desktop".
2) To paraphrase an old, OLD trope which people trot out from time to time---with all it implies---to try to convince others of Linux's ease of use, and ease of installation---
"My Grandma uses Linux, and she's absolutely ecstatic; she's NEVER had a problem."
That, my dear friends, means only two things---YOU set it up for her; and YOU keep it running for her. It does NOT mean anything more, and, most importantly: NOTHING LESS.
Great subject; great comments.
49 • Build it and they will come... (by Friar Tux on 2021-10-07 02:51:31 GMT from Canada)
@46 (Robert) I tend to agree. Most users will use whatever works and stays working. These portable apps are for making the devs' lives easier - and the maintainers'. As I've said many times, MY personal preference is AppImage. One file that will work anywhere and is truely portable (can't say the same for Snaps and Flatpak as I rarely use them due to - issues). We could eliminate a lot of repeated/over-lapping efforts among the various distros if we had "one file to rule them all" instead of numerous different versions of the same app because - distros. I see this containerisation as maybe an even better way. If apps could be containerised with everything they need to work, and distros were set up to accept those containers in lieu of installation then that might be the best method. (Not sure if this is already a thing as I'm still trying to figure out this whole container thing.) One container store/repository for all distros. Ya gotta love that.
50 • Ease of use. (by Friar Tux on 2021-10-07 03:00:04 GMT from Canada)
@49 (R. Cain) You comment popped up after I hit send on my @49 comment. But I very much disagree with your # 2 opinion. I AM THAT GRANDPA! I set up my own computer on Linux after years of using Windows AND I set up and maintain The Wife's computer (also Linux). Linux really is so much easier to use and maintain than Windows - and I do not use CLI, nor do I code in any way.
51 • Portable Apps via Hermit (by Mark on 2021-10-07 04:23:57 GMT from Canada)
Hermit pkgs are an alternative to Appimages. They are ZIP archives that are mounted & run. Appimages are squashFS archives that are mounted & run.
If you build/modify Appimages like me, then you may enjoy playing with Hermit pkgs too. The author's shell-scripts are accessible & innovative when studied. I have modified them for myself to add to the fun.
Get the Hermit app at : sourceforge.net/projects/hermit-tool/
52 • @7 Ansible with 1000 servers (by far2fish on 2021-10-07 10:56:23 GMT from Denmark)
I bet you already have an inventory somewhere with details of these servers? Or if you use a management tool like vSphere it got APIs to get these server details, and as someone previousy said, you can use dynamic inventory to get that into a format that Ansible accepts. You can for instance write that in Python dynamically, or a one-off to convert it to YAML in Ansible inventory format.
The second point is that an alternative to password based logins, is the (PKI) key based login that would be preferable, which Ansible also support, since Ansible at the end of the day is basically only Python code being transferred and executed over SSH.
53 • @49 Proverbial Grandma: (by dragonmouth on 2021-10-07 13:05:14 GMT from United States)
""My Grandma uses Linux, and she's absolutely ecstatic; she's NEVER had a problem."
That, my dear friends, means only two things---YOU set it up for her; and YOU keep it running for her. It does NOT mean anything more, and, most importantly: NOTHING LESS."
Same can be said if Grandma is using Windows.
There is a big difference between "using" and "running" an O/S. To bring up a hackneyed analogy - the car. Most drivers only "use" a car. All they know how to do, or want to do, is to hold on to the steering wheel, step on the gas and the brake, and get from point A to point B. Those are your Grandmas Then you have the people that do various amounts of maintenance on their cars from just checking and topping off fluids to rebuilding and replacing various components. These are the ones that are "running" their cars.
54 • Maintenance (by Tad Strange on 2021-10-07 15:04:26 GMT from Canada)
@50
You're right in that regard. Windows has become so laden down with the "for dummies" approach that it has become utterly frustrating to maintain in any way other than just leaving it alone and hoping that it sorts itself out.
I can never even force the time to sync, and I do not think that I have EVER had this work. (It's become an issue in dual boot environments where Linux keeps adjusting my hardware clock, which I kind of hate..). A call to an NTP server should be simple, not blood boiling...
Microsoft has been trying to turn the PC into an appliance for years, and really fails at it. Only Google has managed this, but then Chromebooks are a doubly-walled garden of both curated hard and software.
55 • The Battle for the System Clock (by Kyle on 2021-10-07 15:51:40 GMT from United States)
@54 It is possible to force Windows to interpret the system clock as UTC instead of local time, which should put an end to the time standard war on your dual-boot. Naturally, the setting is hidden deep in the Registry, but in my experience I've been able set it once and then forget about it. The Arch Wiki has some clear instructions for this: https://wiki.archlinux.org/title/System_time#UTC_in_Microsoft_Windows
It is also possible to force Linux to interpret the system clock as local time if you'd prefer to conform to Windows' default behavior, but this approach seems to be frowned upon by distro maintainers. The method for doing this depends on the init system. That Arch Wiki page has instructions for using systemd's timedatectl a bit further up on the page. The OpenRC section of the Gentoo handbook mentions a configuration file at "/etc/conf.d/hwclock": https://wiki.gentoo.org/wiki/System_time#OpenRC_2
56 • old people and linux (by Otis on 2021-10-07 16:56:34 GMT from United States)
That post up there by R. Cain is mindless (the "gramma" thing). My god man I'm 75 and started linux in 1995. My friends at work back then, most my age were exchanging tips and tricks on everything from Mandrake to Yoper and everything in between FOR DECADES.
What the hell, ageism in the Linux community? Get off it.
57 • @51 Hermit (by Ostro on 2021-10-07 18:05:22 GMT from Poland)
How about giving more info on how to use Hermit? How to create an app, how to deploy it, etc?
58 • Year of Linux (by Justin on 2021-10-07 21:36:59 GMT from United States)
The year of the Linux desktop has already happened. It's called the Chromebook.
The same is true for Linux on mobile: Android. What do these have in common? A company put together something users wanted. Linux freedom as most of us know it is nowhere to be found. Gnome, systemd, snaps, flatpaks, Wayland, Pulse Audio... all these debates show why.
Also notice what most of those debates also have in common.
59 • Linux Freedom? (by Friar Tux on 2021-10-08 04:14:30 GMT from Canada)
@58 (Justin) "Linux freedom as most of us know it is nowhere to be found."
Not sure why you think that. I am free to choose Gnome or not, systemd or not, snaps/flatpaks or not, etc., etc.. I can run a distro with or without any of them, or even any combination of them. So again, what exactly are you trying to say, here?
I do agree that the year of the Linux desktop has been with us for a while. Sure the market share isn't as big as Microsoft, but it's there and growing.
60 • @53 old people and linux (by mandog on 2021-10-08 09:53:43 GMT from United Kingdom)
That, my dear friends, means only two things---YOU set it up for her; and YOU keep it running for her. It does NOT mean anything more, and, most importantly: NOTHING LESS."
Same can be said if Grandma is using Windows.
That is a load of incrimination against old people I'm 73 and run pure Arch and know many people much older than me running Linux, also many younger that cant install windows let alone anything else
61 • Ansible, packages (by Quazatron on 2021-10-08 15:52:07 GMT from Portugal)
Ansible is a great little tool, but note that it requires more that just SSH to work. It also requires both source and target machines to have a supported version of Python installed.
Regarding packages, I will use native distro packages first, if available. For alien apps that I am forced to use, (like Teams), I'd rather use a containerized app.
It is a pain that the some stores (like Gnome) do not clearly separate between native packages and portable packages.
Number of Comments: 61
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 1087 (2024-09-09): COSMIC desktop, running cron jobs at variable times, UBports highlights new apps, HardenedBSD offers work around for FreeBSD change, Debian considers how to cull old packages, systemd ported to musl |
| • Issue 1086 (2024-09-02): Vanilla OS 2, command line tips for simple tasks, FreeBSD receives investment from STF, openSUSE Tumbleweed update can break network connections, Debian refreshes media |
| • Issue 1085 (2024-08-26): Nobara 40, OpenMandriva 24.07 "ROME", distros which include source code, FreeBSD publishes quarterly report, Microsoft updates breaks Linux in dual-boot environments |
| • Issue 1084 (2024-08-19): Liya 2.0, dual boot with encryption, Haiku introduces performance improvements, Gentoo dropping IA-64, Redcore merges major upgrade |
| • Issue 1083 (2024-08-12): TrueNAS 24.04.2 "SCALE", Linux distros for smartphones, Redox OS introduces web server, PipeWire exposes battery drain on Linux, Canonical updates kernel version policy |
| • Issue 1082 (2024-08-05): Linux Mint 22, taking snapshots of UFS on FreeBSD, openSUSE updates Tumbleweed and Aeon, Debian creates Tiny QA Tasks, Manjaro testing immutable images |
| • Issue 1081 (2024-07-29): SysLinuxOS 12.4, OpenBSD gain hardware acceleration, Slackware changes kernel naming, Mint publishes upgrade instructions |
| • Issue 1080 (2024-07-22): Running GNU/Linux on Android with Andronix, protecting network services, Solus dropping AppArmor and Snap, openSUSE Aeon Desktop gaining full disk encryption, SUSE asks openSUSE to change its branding |
| • Issue 1079 (2024-07-15): Ubuntu Core 24, hiding files on Linux, Fedora dropping X11 packages on Workstation, Red Hat phasing out GRUB, new OpenSSH vulnerability, FreeBSD speeds up release cycle, UBports testing new first-run wizard |
| • Issue 1078 (2024-07-08): Changing init software, server machines running desktop environments, OpenSSH vulnerability patched, Peppermint launches new edition, HardenedBSD updates ports |
| • Issue 1077 (2024-07-01): The Unity and Lomiri interfaces, different distros for different tasks, Ubuntu plans to run Wayland on NVIDIA cards, openSUSE updates Leap Micro, Debian releases refreshed media, UBports gaining contact synchronisation, FreeDOS celebrates its 30th anniversary |
| • Issue 1076 (2024-06-24): openSUSE 15.6, what makes Linux unique, SUSE Liberty Linux to support CentOS Linux 7, SLE receives 19 years of support, openSUSE testing Leap Micro edition |
| • Issue 1075 (2024-06-17): Redox OS, X11 and Wayland on the BSDs, AlmaLinux releases Pi build, Canonical announces RISC-V laptop with Ubuntu, key changes in systemd |
| • Issue 1074 (2024-06-10): Endless OS 6.0.0, distros with init diversity, Mint to filter unverified Flatpaks, Debian adds systemd-boot options, Redox adopts COSMIC desktop, OpenSSH gains new security features |
| • Issue 1073 (2024-06-03): LXQt 2.0.0, an overview of Linux desktop environments, Canonical partners with Milk-V, openSUSE introduces new features in Aeon Desktop, Fedora mirrors see rise in traffic, Wayland adds OpenBSD support |
| • Issue 1072 (2024-05-27): Manjaro 24.0, comparing init software, OpenBSD ports Plasma 6, Arch community debates mirror requirements, ThinOS to upgrade its FreeBSD core |
| • Issue 1071 (2024-05-20): Archcraft 2024.04.06, common command line mistakes, ReactOS imports WINE improvements, Haiku makes adjusting themes easier, NetBSD takes a stand against code generated by chatbots |
| • Issue 1070 (2024-05-13): Damn Small Linux 2024, hiding kernel messages during boot, Red Hat offers AI edition, new web browser for UBports, Fedora Asahi Remix 40 released, Qubes extends support for version 4.1 |
| • Issue 1069 (2024-05-06): Ubuntu 24.04, installing packages in alternative locations, systemd creates sudo alternative, Mint encourages XApps collaboration, FreeBSD publishes quarterly update |
| • Issue 1068 (2024-04-29): Fedora 40, transforming one distro into another, Debian elects new Project Leader, Red Hat extends support cycle, Emmabuntus adds accessibility features, Canonical's new security features |
| • Issue 1067 (2024-04-22): LocalSend for transferring files, detecting supported CPU architecure levels, new visual design for APT, Fedora and openSUSE working on reproducible builds, LXQt released, AlmaLinux re-adds hardware support |
| • Issue 1066 (2024-04-15): Fun projects to do with the Raspberry Pi and PinePhone, installing new software on fixed-release distributions, improving GNOME Terminal performance, Mint testing new repository mirrors, Gentoo becomes a Software In the Public Interest project |
| • Issue 1065 (2024-04-08): Dr.Parted Live 24.03, answering questions about the xz exploit, Linux Mint to ship HWE kernel, AlmaLinux patches flaw ahead of upstream Red Hat, Calculate changes release model |
| • Issue 1064 (2024-04-01): NixOS 23.11, the status of Hurd, liblzma compromised upstream, FreeBSD Foundation focuses on improving wireless networking, Ubuntu Pro offers 12 years of support |
| • Issue 1063 (2024-03-25): Redcore Linux 2401, how slowly can a rolling release update, Debian starts new Project Leader election, Red Hat creating new NVIDIA driver, Snap store hit with more malware |
| • Issue 1062 (2024-03-18): KDE neon 20240304, changing file permissions, Canonical turns 20, Pop!_OS creates new software centre, openSUSE packages Plasma 6 |
| • Issue 1061 (2024-03-11): Using a PinePhone as a workstation, restarting background services on a schedule, NixBSD ports Nix to FreeBSD, Fedora packaging COSMIC, postmarketOS to adopt systemd, Linux Mint replacing HexChat |
| • Issue 1060 (2024-03-04): AV Linux MX-23.1, bootstrapping a network connection, key OpenBSD features, Qubes certifies new hardware, LXQt and Plasma migrate to Qt 6 |
| • Issue 1059 (2024-02-26): Warp Terminal, navigating manual pages, malware found in the Snap store, Red Hat considering CPU requirement update, UBports organizes ongoing work |
| • Issue 1058 (2024-02-19): Drauger OS 7.6, how much disk space to allocate, System76 prepares to launch COSMIC desktop, UBports changes its version scheme, TrueNAS to offer faster deduplication |
| • Issue 1057 (2024-02-12): Adelie Linux 1.0 Beta, rolling release vs fixed for a smoother experience, Debian working on 2038 bug, elementary OS to split applications from base system updates, Fedora announces Atomic Desktops |
| • Issue 1056 (2024-02-05): wattOS R13, the various write speeds of ISO writing tools, DSL returns, Mint faces Wayland challenges, HardenedBSD blocks foreign USB devices, Gentoo publishes new repository, Linux distros patch glibc flaw |
| • Issue 1055 (2024-01-29): CNIX OS 231204, distributions patching packages the most, Gentoo team presents ongoing work, UBports introduces connectivity and battery improvements, interview with Haiku developer |
| • Issue 1054 (2024-01-22): Solus 4.5, comparing dd and cp when writing ISO files, openSUSE plans new major Leap version, XeroLinux shutting down, HardenedBSD changes its build schedule |
| • Issue 1053 (2024-01-15): Linux AI voice assistants, some distributions running hotter than others, UBports talks about coming changes, Qubes certifies StarBook laptops, Asahi Linux improves energy savings |
| • Issue 1052 (2024-01-08): OpenMandriva Lx 5.0, keeping shell commands running when theterminal closes, Mint upgrades Edge kernel, Vanilla OS plans big changes, Canonical working to make Snap more cross-platform |
| • Issue 1051 (2024-01-01): Favourite distros of 2023, reloading shell settings, Asahi Linux releases Fedora remix, Gentoo offers binary packages, openSUSE provides full disk encryption |
| • Issue 1050 (2023-12-18): rlxos 2023.11, renaming files and opening terminal windows in specific directories, TrueNAS publishes ZFS fixes, Debian publishes delayed install media, Haiku polishes desktop experience |
| • Issue 1049 (2023-12-11): Lernstick 12, alternatives to WINE, openSUSE updates its branding, Mint unveils new features, Lubuntu team plans for 24.04 |
| • Issue 1048 (2023-12-04): openSUSE MicroOS, the transition from X11 to Wayland, Red Hat phasing out X11 packages, UBports making mobile development easier |
| • Issue 1047 (2023-11-27): GhostBSD 23.10.1, Why Linux uses swap when memory is free, Ubuntu Budgie may benefit from Wayland work in Xfce, early issues with FreeBSD 14.0 |
| • Issue 1046 (2023-11-20): Slackel 7.7 "Openbox", restricting CPU usage, Haiku improves font handling and software centre performance, Canonical launches MicroCloud |
| • Issue 1045 (2023-11-13): Fedora 39, how to trust software packages, ReactOS booting with UEFI, elementary OS plans to default to Wayland, Mir gaining ability to split work across video cards |
| • Issue 1044 (2023-11-06): Porteus 5.01, disabling IPv6, applications unique to a Linux distro, Linux merges bcachefs, OpenELA makes source packages available |
| • Issue 1043 (2023-10-30): Murena Two with privacy switches, where old files go when packages are updated, UBports on Volla phones, Mint testing Cinnamon on Wayland, Peppermint releases ARM build |
| • Issue 1042 (2023-10-23): Ubuntu Cinnamon compared with Linux Mint, extending battery life on Linux, Debian resumes /usr merge, Canonical publishes fixed install media |
| • Issue 1041 (2023-10-16): FydeOS 17.0, Dr.Parted 23.09, changing UIDs, Fedora partners with Slimbook, GNOME phasing out X11 sessions, Ubuntu revokes 23.10 install media |
| • Issue 1040 (2023-10-09): CROWZ 5.0, changing the location of default directories, Linux Mint updates its Edge edition, Murena crowdfunding new privacy phone, Debian publishes new install media |
| • Issue 1039 (2023-10-02): Zenwalk Current, finding the duration of media files, Peppermint OS tries out new edition, COSMIC gains new features, Canonical reports on security incident in Snap store |
| • Issue 1038 (2023-09-25): Mageia 9, trouble-shooting launchers, running desktop Linux in the cloud, New documentation for Nix, Linux phasing out ReiserFS, GNU celebrates 40 years |
| • Issue 1037 (2023-09-18): Bodhi Linux 7.0.0, finding specific distros and unified package managemnt, Zevenet replaced by two new forks, openSUSE introduces Slowroll branch, Fedora considering dropping Plasma X11 session |
| • Issue 1036 (2023-09-11): SDesk 2023.08.12, hiding command line passwords, openSUSE shares contributor survery results, Ubuntu plans seamless disk encryption, GNOME 45 to break extension compatibility |
| • Issue 1035 (2023-09-04): Debian GNU/Hurd 2023, PCLinuxOS 2023.07, do home users need a firewall, AlmaLinux introduces new repositories, Rocky Linux commits to RHEL compatibility, NetBSD machine runs unattended for nine years, Armbian runs wallpaper contest |
| • Issue 1034 (2023-08-28): Void 20230628, types of memory usage, FreeBSD receives port of Linux NVIDIA driver, Fedora plans improved theme handling for Qt applications, Canonical's plans for Ubuntu |
| • Issue 1033 (2023-08-21): MiniOS 20230606, system user accounts, how Red Hat clones are moving forward, Haiku improves WINE performance, Debian turns 30 |
| • 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 | 
ALT Linux
ALT Linux was founded in 2001 by a merge of two large Russian free software projects. By the year 2008 it became a large organization developing and deploying free software, writing documentation and technical literature, supporting users, and developing custom products. ALT Linux produces different types of distributions for various purposes. There are desktop distributions for home and office computers and for corporate servers, universal distributions that include a wide variety of development tools and documentation, certified products, distributions specialized for educational institutions, and distributions for low-powered computers. ALT Linux has its own development infrastructure and repository called Sisyphus, which provides the base for all the different editions of ALT Linux.
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.
|
|
• 
• 
• 
• 
• 
• 
• 
0x969CD4E778C7b6549A2B00e34114e0168c86A542 
