 DistroWatch Weekly |
| Tip Jar |
If you've enjoyed this week's issue of DistroWatch Weekly, please consider sending us a tip.
(Tips this week: 0, value: US$0.00) |
|
|
|
 bc1qtede6f7adcce4kjpgx0e5j68wwgtdxrek2qvc4  lnurl1dp68gurn8ghj7ampd3kx2ar0veekzar0wd5xjtnrdakj7tnhv4kxctttdehhwm30d3h82unvwqhhxarpw3jkc7tzw4ex6cfexyfua2nr  86fA3qPTeQtNb2k1vLwEQaAp3XxkvvvXt69gSG5LGunXXikK9koPWZaRQgfFPBPWhMgXjPjccy9LA9xRFchPWQAnPvxh5Le paypal.me/distrowatchweekly • patreon.com/distrowatch |
|
| Linux Foundation Training |
|
| Reader Comments • Jump to last comment |
1 • Snap-Crap (by Bob on 2021-10-11 00:26:55 GMT from United States)
I will continue to avoid Snap.
I won't even buy Cheez-It Snap'd crackers.
2 • "Are you more likely to use Snap now that third-party repositories are possible? (by R. Cain on 2021-10-11 00:27:30 GMT from United States)
There are times when a one-word answer says far more than more words ever could.
I would have preferred for one of the choices to have been
"No".
3 • Snaps (by Shawn Rogers on 2021-10-11 00:58:58 GMT from United States)
I won't use snaps because each installed package has to be mounted as a block device to run. There are as many as 2-3 mounted loop devices for each snap package cluttering up my lsblk and fdisk outputs. How many block devices would you have mounted if the whole system was snaps?
4 • Snap & the kernel (by vern on 2021-10-11 01:30:04 GMT from United States)
I go Snapless. Is that lol as in laughting-out-loud? If so, that's how I view any Snap distribution.
I feel the same regarding building, compiling the kernel. I did it a few times. Not much gain. I also feel I gain from removing needless services.
5 • Pyabr - 100% cpu, no process monitoring (by Andy Prough on 2021-10-11 01:33:40 GMT from Switzerland)
Got to wonder how much digital coin mining you did without knowing it while you tried that distro out Jesse.
That's a pretty funny experience to read about.
As for snaps - I have a funny feeling that "I will continue to avoid" is somehow going to be the runaway winner.
6 • No to Snap! (by Torsten on 2021-10-11 01:45:33 GMT from Germany)
Snap is crap! So, no!
7 • Linux kernel, from source, self-compiled, or other? (by Greg Zeng on 2021-10-11 02:05:26 GMT from Australia)
The newest Linux kernels are released every day, as raw source code, by "The Linux Foundation". These releases are usually bug-fixes & optimizations on previous releases of earlier versions of the Kernel.
The very latest & newest kernel has included some source code injected by commercial products, such as Microsoft, Intel, AMD, Samsung, etc. These lines of source code can be removed, as necessary.
These source codes can then be selected with various compromises & optimization types: different hardware settings, for speed, power efficiencies. Ubuntu (different from Canonical & Red Hat, as organizations) releases it's compiled versions of the source code, with additions added, that are not included in the official source code from The Linux Foundation. Ubuntu offers the compiled code for the main few CPU types in either "normal" or as "low latency". There seems to be no independent bench tests on the difference between these two different kernels.
This compiled code from Ubuntu is released seconds after the raw source code is openly publicly released. Only certain versions of the Ubuntu compilations are officially added into the complete Ubuntu family operating systems.
Red Hat & other operating systems offer only a very small percentage of the available kernels. Many private compiled codes add or remove sections that may or may not be described publicly.
All the Ubuntu & most Debian based operating systems can use any of the pre-compiled kernels offered by the official Ubuntu web site. Some non-Ubuntu systems also offer some kernels from this web site.
Self-compiling source code requires skill, time and enough computer power, so most users prefer pre-compiled code. The extreme very latest code generally is not needed by most users. The system update processes generally cannot keep pace with the very latest releases.
8 • Compiling a kernel (by Gary W on 2021-10-11 02:08:28 GMT from Australia)
I haven't done this for probably 20 years. To suit a machine with 16 meg (not gig) of RAM. After several attempts to remove enough (but not too much), I had a working custom kernel which saved 1 megabyte. A noticeable improvement on this machine, but significantly not worth it on any more capable system. So, never again :-)
As for snaps, not today thanks!
9 • Snap, flatpak or any other shit? (by Jyrki on 2021-10-11 03:44:03 GMT from Czechia)
No, thank you. I am happy with status quo and what my distro offer
10 • Compiling Kernel and Gentoo News Item (by Andy Figueroa on 2021-10-11 03:54:57 GMT from United States)
I run Gentoo on my main desktop so configuring and compiling the kernel has been routine for about 17 years. But, if I was running another distribution with no kernel/driver issues, I would not configure and compile a custom kernel. All binary distributions represent compromises across the board in both kernel and userland, so it's not worth the chase to try to optimize just the kernel. Most mainstream distributions ship satisfactory kernels that support most hardware out-of-the-box.
Cribbing off of a Redcore announcement in order to publicize an issue in Gentoo Portage that was announced directly by Gentoo in a news feed seems like sniping. The original news item which is duplicated in the Redcore announcement is found at: https://www.gentoo.org/support/news-items/2021-09-29-possible-failure-to-preserve-libraries.html
11 • Snap?, LOL (by nsp0323 on 2021-10-11 04:39:03 GMT from Sweden)
Visiting lol repository will show, "Archived project! Repository and other project resources are read-only".
So much for an alternative. Not that I care, would never use it anyway.
12 • snap (by dave on 2021-10-11 05:03:06 GMT from United States)
What we need is a super bloated, er I mean 'fortified' Gnome Shell fork called Crackle so we can have Snap, Crackle, Pop!_OS
Please somebody do this
13 • Snap (by T-Khan on 2021-10-11 05:26:48 GMT from Russia)
The real problem for me with snaps are forced updates. So, no.
14 • I left Ubuntu Mate because of snap (by Mahmut Erogul on 2021-10-11 09:24:08 GMT from Turkey)
having a filesystem with duplicates of libraries for distributions main applications (sound, wellcome, application store) made me mad and I left Ubuntu Mate, moved to Linux Mint; then to Manjaro (uninstalled snap). I will NEVER use snap, it is a conceptual mistake, Canonicals attitude of forcing the users to snap will backfire them.
15 • Snap (by Nerone on 2021-10-11 09:55:54 GMT from Italy)
I don't use Snap or Flatpak. I find Appimage applications useful in some cases.
16 • snap (by geppo on 2021-10-11 10:41:44 GMT from Italy)
snap works really really bad, totally unuseful for me
17 • Snaps (by James on 2021-10-11 11:05:33 GMT from United States)
3 • Snaps (by Shawn Rogers "I won't use snaps because each installed package has to be mounted as a block device to run. There are as many as 2-3 mounted loop devices for each snap package cluttering up my lsblk and fdisk outputs. How many block devices would you have mounted if the whole system was snaps?" Amen to that!
14 • I left Ubuntu Mate because of snap. Me too!
18 • Gentoo distribution kernels (by kernel compiler on 2021-10-11 11:49:00 GMT from Germany)
With Gentoo it was always necessary to compile the Linux kernel. Gentoo used to offer only two options: completely manual (which sounds harder than it is), or by means of the "genkernel" tool.
Lately Gentoo also offers "distribution kernels" as a source package. It makes installing a kernel as simple as any other Gentoo package. It requires no specific knowledge to compile your own kernel this way.
19 • Snap poll (by Otis on 2021-10-11 11:59:35 GMT from United States)
Thanks for "undecided." I have no idea the relative benefits or issues at hand about snap. All I know is it's developed by Canonical, so that seems like the best reason to not have it. As far as I know, MX Linux, my main distro, does not deploy snap (or systemd).
20 • Upcoming Releases (by Beastie on 2021-10-11 12:12:38 GMT from Switzerland)
There's an error in the Upcoming Releases section: FreeBSD 12.2 was released last year, the version to be released in December is 12.3.
21 • Compling kernels and SNAPS (by Tricyx on 2021-10-11 12:25:02 GMT from United States)
I only compile occasionally, more to see what is/is not included. It's also nice to remove bluetooth; wireless; WAN; wacom; etc... hardware modules that seem to be added as the default built in or moduled anymore. Little nuts that some of that is included for a desktop machine that's hardwired.
20 years ago, we didn't have the optimized pre-built options we have today. Between Zen; PF; low-latency; xanmod; hardened; etc... kernels, you can find one that suites your needs and don't really need to compile from source, unless either 1) you really want to 2) something very specific applies to your system 3) save space.
As for Snaps, I haven't had a single good experience with them. Even on Ubuntu Server, all it does is chew up ram and forces you into an architecture you don't want (I like to compare it to Cortana; XBox; or touch features on Windows Server editions). One of the first things I do: apt remove --purge snapd. Flatpak and Appimage are significantly more fleshed out, and here's hoping Canonical realizes it's not worth it and goes the way of Unity.
22 • SNAPS (by dragonmouth on 2021-10-11 12:42:17 GMT from United States)
In a word - NO!.
It's from Canonical. Enough said.
23 • Snap on Ubuntu (by Fabio on 2021-10-11 13:19:01 GMT from Italy)
As @17 I am annoyed by the block devices cluttering with snap. So
my first action after installing Ubuntu is totally removing snapd from the system.
Conversely I moderately use the Flatpak package. In particular in
Ubuntu 20.04 I use Flatpak to install VLC media player because the official VLC version
in Ubuntu 20.04 has bugs and backporting of a newer version is very difficult.
This is a case in which Flatpak is very useful and running fine
24 • Snap and systemd (by Jesse on 2021-10-11 13:44:42 GMT from Canada)
>> "As far as I know, MX Linux, my main distro, does not deploy snap (or systemd)."
You are mostly correct. MX Linux uses SysV init by default. They do provide systemd for people who want to use it, but the default is to make init SysV init. As a result MX Linux doesn't use Snap packages because the Snap framework requires systemd to be running. If your distribution does not run systemd then you can't make use of Snap packages.
25 • Snaps (by DachshundMan on 2021-10-11 13:55:58 GMT from United Kingdom)
Do not use them unless there is no alternative at all. They are just bloatware. It is partly why I swapped from Ubuntu to Mint, that and Unity were the main deciders.
26 • Snaps (by Mocha on 2021-10-11 14:34:10 GMT from United States)
I think the idea that snaps have, as a somewhat integrated universal package, is a good idea. Their execution, though, is rather poor. It's a touch bloated and it's lockdown by canonical makes it far worse than what it should be. I feel if we branch out, try and make something better, and improve on it's faults, we could have the next appimage. But for now? I'd rather write a new distro by hand than use snaps.
27 • Flat-snap-crap (by Bob on 2021-10-11 15:16:03 GMT from United States)
I browsed Flathub to see if it might be worth a risk. They have a lot of STUFF, but nothing I want.
I tried snap back when Ubuntu abandoned Chromium. Total garbage. Chromium ran poorly, didn't integrate with the gtk theme, AND the snap folder is parked right there in my home directory. WHY? At least put it in the .conf directory!
That snap/Chromium fiasco led me to Brave browser, but I abandoned the deb-ubuntu systems altogether.
Now I'm on Manjaro...everyting I want is there. Perfect.
28 • Snaps and kernel builds (by Donaudumpfschiffarts... on 2021-10-11 15:42:54 GMT from United States)
I've built a few kernels in the past, like 20 yrs ago. But it is a long process, and I get kernel updates often enuf that I don't want to rebuild every time.
As for snaps...that's one of the reasons I left Ubuntu after 10 years. There were several others (like constant paper cuts, apathy, and their dictatorial attitude). I'll use AppImages, but only if I have to. The distros I use now don't seem to have too much problem keeping regular packages in their repos.
Maybe its time we realize that dynamic linking was good for the times, but the times now call for a return to static linking. At least for individual users.
29 • Snaps (by Robert on 2021-10-11 15:47:33 GMT from United States)
While being able to use alternative repositories does raise my opinion of snaps, I still rank it below every other option.
30 • Oh....Snap! (by Mike on 2021-10-11 16:27:29 GMT from United Kingdom)
I purged snapd and Discover support for it from my kubuntu (and neon in VM) system straight after install. I did the same with LVFS as my core system hardware is legacy and if something needs it (newer SSD from crucial for example) I can update manually myself.
It actually makes Discover more responsive not having snap or lvfs enabled so win win.
I'll continue to use the Official Mozilla PPA for Thunderbird as long as it is available, the same goes for LibreOffice Community Fresh.
31 • @24 • Snap and systemd (by Jesse...) (by R. Cain on 2021-10-11 17:21:07 GMT from United States)
"...As a result MX Linux doesn't use Snap packages because the Snap framework requires systemd to be running. If your distribution does not run systemd then you can't make use of Snap packages..."
Clarification, amplification, and the benefit of your expertise are all deeply appreciated.
One more reason to not use any distro which runs systemd Thank you.
32 • @22 • SNAPS (by dragonmouth... (by R. Cain on 2021-10-11 19:47:43 GMT from United States)
"In a word - NO!..."
See comment #2.
33 • Snap (by Elise on 2021-10-11 21:00:18 GMT from Austria)
One reason I love Linux Mint is that instead of following the Ubuntu way, they did not enable Snaps by default, and they did not allow "apt install chromium" to automatically "snap install" Chromium. (How anyone can justify automatically switching "apt install" to "snap install" is beyond comprehension.) Instead, they build their own Chromium package. (And those who want to enable Snaps on Linux Mint can do so.)
34 • Snaps (by Bob McConnell on 2021-10-11 21:57:43 GMT from United States)
It is not even worth considering until it fully supports Slackware and vice versa. I suspect that is not at all likely to happen.
35 • Compiling a Kernel (by crayola eater on 2021-10-11 21:58:34 GMT from United States)
I always told myself that after I retired I would set aside the time to research the hows and build my own kernel. Well, it's now 7 years and counting, and I've moved no closer to that retirement project than any of the others that reside in the closet.
But I still think it would be worth the the time if only for the experience gained.
oh yeah, I vote No to Snaps
36 • Snap (by Mike on 2021-10-11 22:17:29 GMT from United Kingdom)
@33 I was using Linux Mint Cinnamon for some time too and it is still installed on my Mother's PC at present which doesn't appear to suffer the effects of the memory leak my own did. I think it is graphics stack related but you never really know what triggers it, especially when no useful trace from it was ever created even with debug packages installed.
I'm not keen on the plan they have about a preset memory limit for the Cinnamon process which leaks based auto process kill to get round the leak.
If the Linux Mint developers rolled a Plasma ISO I would be on it like a shot. However I am glad they don't really because their speciality and focus should always remain in Cinnamon and it's GTK brethren (MATE and XFCE).
Regarding portable apps - they have embraced Flatpak to a certain extent by publishing their own application Warpinator to it officially.
37 • Compiling and coding. (by Friar Tux on 2021-10-11 22:27:13 GMT from Canada)
@36 (crayola eater) I retired a number of years before I actually retired. I was bored out of my skull, so I went back to work. Then, about 5 years ago, I retired for good. This time I loved it. I had planned a few projects to keep me busy. Got them done the first year. I also had plans to learn to code and build my own systems but that fell by the wayside as being way to redundant and labour intensive. Now I consider myself a "user" (no drugs involved). An artist's work would be useless if no one enjoyed it. An author's writings would be for naught if no one read them. Well, the same goes for coding and compiling, in my opinion. So, I'll use already built OSes and software and such. There is enough repetition of effort in Linux that I don't need to add to it. Now I spend my time playing with the various distros and software to see which one, in my opinion, is REALLY the best. I keep copious note of everything.
38 • SNAP for Me (by MattE on 2021-10-12 01:50:06 GMT from United States)
If it take more than 1 minute to get set up from a normal install or is a general PITA to install, I'll use a snap if available. I'm lazy.
39 • Snap? (by Silent Warrior on 2021-10-12 03:01:05 GMT from Sweden)
To Snap, or not to Snap... I don't really care, honestly. I've heard about some ideological friction between non-Canonical distros and Snap, but for me, personally, I just don't have a use-case where there is a piece (or version) of software I can't find in the normal package database that exists as a Snap. Will consider the question when that situation changes.
('Course, I think my distro straight up blocks Snap now, anyway, so I'd have to go distro-hopping first all the same.)
40 • Pyabr OS Trivia (by Jack on 2021-10-12 08:34:06 GMT from Australia)
The Pyabr OS originated in Iran where Farsi is the official language. The word "abr" means cloud in Farsi. Pyabr is then the equivalent of PyCloud in English.
41 • Snap (by Detmer on 2021-10-12 12:57:54 GMT from Belgium)
Snap? No, thank you. For one thing, snapd has been the laughing stock of software management for several years now. See this bug report (open for five years and counting), especially comment no. 4: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053
For another thing, in the Ubuntu people push the responsibility of making snaps run with acceptable(?) speed to the end users. From the Distrowatch headline quote: "In this article, we want to show you a number of methods and tools you can use to make your snaps snappy." In line with the systemd folks, they sh*t on other peoples desks, then leave the cleaning to those same people.
42 • compiling kernels (by Glenn Condrey on 2021-10-12 13:57:51 GMT from United States)
I compiled my own kernel back when Xandros 3.01 was a thing. It was a mite bit difficult, as they said...that although Xandros was based on Debian...Xandros was NOT Debian...so there were some extra steps involved.
As always...if anything broke in the OS 'broke' while you were compiling things...you got to keep all the pieces.... (meaning you'd have to do an OS re-install.)
As for Snap or Flatpacks, if they make installing a package easier...I'm down for it. I think as they become more common, easier ways to maintain and install will make them more attractive to Linux users than they are now.
43 • Joining the snap dogpile... (by Nathan on 2021-10-12 14:44:44 GMT from United States)
I've used snap for anbox, but being forced to use systemd limits my options, so I abandoned it. It's not that I'm ideological about init software or anything, it's just that being tied to a specific init for something conceptually unrelated is silly. And so, snap goes in my "unportable/distro-specific" mental category, which I realize is precisely the opposite of the cross-platform goals of snap. Ah well.
44 • oh snap (by Tad Strange on 2021-10-12 17:15:53 GMT from Canada)
I run only 1, and only because I'm currently on Kubuntu and that was the simplest way to get this app, so I figured why not.
Once I switch back to Manjaro, or something else non-buntu, I don't know why I'd bother seeking out Snaps when there are better/simpler options.
Maybe someday it will develop into a compelling ecosystem, but I'm certain that it's going to continue being voldemort/systemd to many.
45 • Snap (by AJ Dowell on 2021-10-12 21:40:16 GMT from United States)
I use Snap for Celtx. I'm fine with snaps but whenever possible, I find an alternative. If I can find a .deb, that's what I use. I got tired of editing .py files and dowloading dependencies to get Trelby working properly everytime I updated to a newer Linux OS. I like Celtx and it has other uses than just screenplay writing. I understand there's Lyx with Hollywood script plugin, Libreoffice screenplay template, and so on. Snap makes it simple to get the writing done. My main job is to write. So the answer for me personally is yes to Snaps for now and we will see how it goes later down the road. I would love for someone to make Celtx an AppImage or Trelby into an AppImage.
46 • Snap (by hulondalo on 2021-10-12 21:57:38 GMT from Australia)
snap is unironically inflexible. users'll end up having many copies of same programs like on windows (for instance i now have 5 version of zlib on my pc from total war empire, total war shogun 2, total war rome 2 and total war attila, crusader kings 3; 1 outdated very old python v2 from battlefield 2), wastes more bandwidth and time to update them all, not to mention security concern.
if you want newer software use rolling distros instead. snap is heresy, avoid it if you can.
47 • Celtx and writing apps. (by Mark B on 2021-10-12 22:02:41 GMT from United Kingdom)
@45 I like Celtx too and was disappointed when it moved to subscription model. Since you are a writer you might like the (abandoned but working) Linux version of Scrivener. I have a !licence for the Windows version but use Mint mostly. The program Manuskript looks useful too.
48 • Compiling Kernels (by Eirian on 2021-10-12 23:05:02 GMT from United Kingdom)
For us old timers compiling a kernel with menuconfig was something you did with each new kernel release as there was a must have improvement with each release. It was necessary in the late 1990s to compile the kernel to get printers working and I remember the excitement when the kernel first allowed the use of USB mass storage, but a recompile was required. Compiling a kernel did not require much technical knowledge and did not take too much time even when computers were running off 32MB (not 32GB) of RAM. Modules were a big innovation, but in late 1990s the pre-compiled kernel was monolithic and you had to use menuconfig to switch things you didn't need to M for module. I can't imagine compiling a kernel in an era where Tumbleweed gives you an updated kernel practically every time you update. Maybe if I had kept paying for SuSE boxed editions rather than switching to Debian I might not have had to compile kernels so much. Eventually having to recompile just to use a new printer drove me to switch to Macs, but within a few years I was running Debian PPC on those Macs.
49 • Kernels (by Mike on 2021-10-13 00:03:18 GMT from United Kingdom)
I leave kernels well alone and use what is pre-compiled by the distribution developers (or sourced from upstream repositories by them)
I've always used wired or wireless networked HP laser and inkjet printers and more recently an MFP and never had an issue getting them to print or scan with Linux. More recently the development of driver-less printing has been gathering pace.
Soon all printers regardless of brand should just work at some level with linux, I still prefer the full hplip with GUI package coupled with xsane though and disable ippusbxd and avahi-daemon to avoid persistent duplication of printers.
The only thing I have ever had to do is use kernel boot commands in grub config to address compatibility issues in the past with AMD Kabini when it was still relatively new. Those issues of course were eventually addressed after users including myself reporting them with supporting logs and traces.
50 • Snap, very smart! (or not?) (by Alessandro di Roma on 2021-10-13 08:34:22 GMT from Italy)
Problem: There are N so-called standards! They are too many!
Solution: Let's invent an (N+1)th one!
51 • Snaps (by pepa65 on 2021-10-13 12:55:29 GMT from Thailand)
Hate snaps, if I do install Ubuntu professionally, I remove it. But for personal use I switched from Ubuntu Mate to Mint Mate, Linux Mint explicitly does not integrate snaps.
[As to compiling kernels, did that decades ago, now I don't (need to) bother anymore, too little gain.]
52 • Poll (by Gen 1b on 2021-10-13 22:32:59 GMT from Canada)
In reguards to the poll, I do not use chat programs
53 • Snap alternative (by Otis on 2021-10-13 22:38:39 GMT from United States)
If for various reasons you, like me, don't like the limitations of systemd/snap togetherness.. don't forget about the alternative (with the best name in response to Canonical's tentacles): LOL.
https://gitlab.com/lol-snap/lol
54 • Snap will come (by analogtek on 2021-10-13 23:13:24 GMT from United States)
If the basement boy's want snap to be a standard. It will be a standard. Even if you do not like it-will be.
55 • Snap (by cor on 2021-10-14 03:21:31 GMT from United States)
This is a terrible solution. I absolutely avoid all snaps. I have tried them and found them useless in the limited environment. I would rather compile than be trapped in a snap environment.
56 • lol snap (by Mike on 2021-10-14 08:42:29 GMT from United Kingdom)
@54 that is what is mentioned in this week's distrowatch news. Personally I believe it is a risky proposition as anyone could set up a snap repository and exploit the trust/naivety of people to spread malware for data harvesting (ID or IP theft), ransomware or bitcoin mining.
While the approach Canonical are taking is questionable at best, at least at present there are some code checks in place for any snaps submitted.
I would use Flathub submissions from the genuine developers (Mozilla, VLC, The Document Foundation etc.) over snap still given the choice if no other means of obtaining an application was possible.
I have not tried AppImage yet but probably should check it out too.
57 • Snaps (by LazyBum on 2021-10-14 15:00:21 GMT from United States)
I'll be the voice of dissent here, I love Snaps! Plex was always out of date until I started using the Snap package. I also use a couple of other Snap packages along with some Flatpaks and an appimage for Plexamp. Honestly, I think it's amazing that all these things work (your mileage may vary).
58 • toothpick building with Pyabr (by own worker on 2021-10-15 00:22:41 GMT from France)
"This week we ... look at the unusual Pyabr project. Pyabr seeks to build an operating system ... almost entirely from Python code."
maybe ppl like to do these kinds of projects to demonstrate their skills / create a niche project / get a fan following. IMO Linux is at its best with these kinds of niche & specialized distros. At least they don't copy other ppl's work and just tweak it a little for their own benefit. But if a project is too toothpick-nichie it will probably slowly die.
59 • Linux and its crutches (by whoKnows on 2021-10-15 11:38:54 GMT from Switzerland)
If I've had to write the article about Linux, package management ... AppImage, Flatpak, Snap ... it'd be highly probable beginning somehow like this:
A desperate attempt to turn something useless into something that is still suitable for everyday usage.
Linux on the desktop is a self-inflicted accident, based on a totally broken basic concept ...
60 • *Snap* goes the code (by Cheker on 2021-10-15 13:38:45 GMT from Portugal)
Anything I could've said about Snap was already said, though to be honest my personal experience wasn't super, super bad.
I used the snaps for Brave and Notepadqq on Debian. I gave up on them after repeated failed attempts at giving Notepadqq write permission to essentially everywhere you'd expect to have it. I ditched it for the native Pluma.
As for Brave, it didn't actually give me any problems, it's just that it's my secondary browser that I barely use, I felt it was pointless to keep the snap framework in place just for it, so I ditched it for the native Chromium.
61 • Flutter OS (by erok on 2021-10-15 15:08:50 GMT from United States)
...It's only a matter of time.
I found the concept of a de-branded HP laptop hilarious. Looking at a mint ZE460 that still works and is built great. There's an HP badge in the webcam spot.
62 • Elementary OS (by Hollywood on 2021-10-15 16:00:39 GMT from United States)
I wish they would include an option to disable or at least deley and \ or choose when and how offten the os checks for updates. it is madding at times with how offten it will pop up saying theres an update, after you update the darn thing.
Number of Comments: 62
Display mode: DWW Only • Comments Only • Both DWW and Comments
| | |
| TUXEDO |
TUXEDO Computers - Linux Hardware in a tailor made suite
Choose from a wide range of laptops and PCs in various sizes and shapes at TUXEDOComputers.com. Every machine comes pre-installed and ready-to-run with Linux. Full 24 months of warranty and lifetime support included!
Learn more about our full service package and all benefits from buying at TUXEDO.
|
| Archives |
| • Issue 1048 (2023-12-04): openSUSE MicroOS, the transition from X11 to Wayland, Red Hat phasing out X11 packages, UBports making mobile development easier |
| • Issue 1047 (2023-11-27): GhostBSD 23.10.1, Why Linux uses swap when memory is free, Ubuntu Budgie may benefit from Wayland work in Xfce, early issues with FreeBSD 14.0 |
| • Issue 1046 (2023-11-20): Slackel 7.7 "Openbox", restricting CPU usage, Haiku improves font handling and software centre performance, Canonical launches MicroCloud |
| • Issue 1045 (2023-11-13): Fedora 39, how to trust software packages, ReactOS booting with UEFI, elementary OS plans to default to Wayland, Mir gaining ability to split work across video cards |
| • Issue 1044 (2023-11-06): Porteus 5.01, disabling IPv6, applications unique to a Linux distro, Linux merges bcachefs, OpenELA makes source packages available |
| • Issue 1043 (2023-10-30): Murena Two with privacy switches, where old files go when packages are updated, UBports on Volla phones, Mint testing Cinnamon on Wayland, Peppermint releases ARM build |
| • Issue 1042 (2023-10-23): Ubuntu Cinnamon compared with Linux Mint, extending battery life on Linux, Debian resumes /usr merge, Canonical publishes fixed install media |
| • Issue 1041 (2023-10-16): FydeOS 17.0, Dr.Parted 23.09, changing UIDs, Fedora partners with Slimbook, GNOME phasing out X11 sessions, Ubuntu revokes 23.10 install media |
| • Issue 1040 (2023-10-09): CROWZ 5.0, changing the location of default directories, Linux Mint updates its Edge edition, Murena crowdfunding new privacy phone, Debian publishes new install media |
| • Issue 1039 (2023-10-02): Zenwalk Current, finding the duration of media files, Peppermint OS tries out new edition, COSMIC gains new features, Canonical reports on security incident in Snap store |
| • Issue 1038 (2023-09-25): Mageia 9, trouble-shooting launchers, running desktop Linux in the cloud, New documentation for Nix, Linux phasing out ReiserFS, GNU celebrates 40 years |
| • Issue 1037 (2023-09-18): Bodhi Linux 7.0.0, finding specific distros and unified package managemnt, Zevenet replaced by two new forks, openSUSE introduces Slowroll branch, Fedora considering dropping Plasma X11 session |
| • Issue 1036 (2023-09-11): SDesk 2023.08.12, hiding command line passwords, openSUSE shares contributor survery results, Ubuntu plans seamless disk encryption, GNOME 45 to break extension compatibility |
| • Issue 1035 (2023-09-04): Debian GNU/Hurd 2023, PCLinuxOS 2023.07, do home users need a firewall, AlmaLinux introduces new repositories, Rocky Linux commits to RHEL compatibility, NetBSD machine runs unattended for nine years, Armbian runs wallpaper contest |
| • Issue 1034 (2023-08-28): Void 20230628, types of memory usage, FreeBSD receives port of Linux NVIDIA driver, Fedora plans improved theme handling for Qt applications, Canonical's plans for Ubuntu |
| • Issue 1033 (2023-08-21): MiniOS 20230606, system user accounts, how Red Hat clones are moving forward, Haiku improves WINE performance, Debian turns 30 |
| • Issue 1032 (2023-08-14): MX Linux 23, positioning new windows on the desktop, Linux Containers adopts LXD fork, Oracle, SUSE, and CIQ form OpenELA |
| • Issue 1031 (2023-08-07): Peppermint OS 2023-07-01, preventing a file from being changed, Asahi Linux partners with Fedora, Linux Mint plans new releases |
| • Issue 1030 (2023-07-31): Solus 4.4, Linux Mint 21.2, Debian introduces RISC-V support, Ubuntu patches custom kernel bugs, FreeBSD imports OpenSSL 3 |
| • Issue 1029 (2023-07-24): Running Murena on the Fairphone 4, Flatpak vs Snap sandboxing technologies, Redox OS plans to borrow Linux drivers to expand hardware support, Debian updates Bookworm media |
| • Issue 1028 (2023-07-17): KDE Connect; Oracle, SUSE, and AlmaLinux repsond to Red Hat's source code policy change, KaOS issues media fix, Slackware turns 30; security and immutable distributions |
| • Issue 1027 (2023-07-10): Crystal Linux 2023-03-16, StartOS (embassyOS 0.3.4.2), changing options on a mounted filesystem, Murena launches Fairphone 4 in North America, Fedora debates telemetry for desktop team |
| • Issue 1026 (2023-07-03): Kumander Linux 1.0, Red Hat changing its approach to sharing source code, TrueNAS offers SMB Multichannel, Zorin OS introduces upgrade utility |
| • Issue 1025 (2023-06-26): KaOS with Plasma 6, information which can leak from desktop environments, Red Hat closes door on sharing RHEL source code, SUSE introduces new security features |
| • Issue 1024 (2023-06-19): Debian 12, a safer way to use dd, Debian releases GNU/Hurd 2023, Ubuntu 22.10 nears its end of life, FreeBSD turns 30 |
| • Issue 1023 (2023-06-12): openSUSE 15.5 Leap, the differences between independent distributions, openSUSE lengthens Leap life, Murena offers new phone for North America |
| • Issue 1022 (2023-06-05): GetFreeOS 2023.05.01, Slint 15.0-3, Liya N4Si, cleaning up crowded directories, Ubuntu plans Snap-based variant, Red Hat dropping LireOffice RPM packages |
| • Issue 1021 (2023-05-29): rlxos GNU/Linux, colours in command line output, an overview of Void's unique features, how to use awk, Microsoft publishes a Linux distro |
| • Issue 1020 (2023-05-22): UBports 20.04, finding another machine's IP address, finding distros with a specific kernel, Debian prepares for Bookworm |
| • Issue 1019 (2023-05-15): Rhino Linux (Beta), checking which applications reply on a package, NethServer reborn, System76 improving application responsiveness |
| • Issue 1018 (2023-05-08): Fedora 38, finding relevant manual pages, merging audio files, Fedora plans new immutable edition, Mint works to fix Secure Boot issues |
| • Issue 1017 (2023-05-01): Xubuntu 23.04, Debian elects Project Leaders and updates media, systemd to speed up restarts, Guix System offering ground-up source builds, where package managers install files |
| • Issue 1016 (2023-04-24): Qubes OS 4.1.2, tracking bandwidth usage, Solus resuming development, FreeBSD publishes status report, KaOS offers preview of Plasma 6 |
| • Issue 1015 (2023-04-17): Manjaro Linux 22.0, Trisquel GNU/Linux 11.0, Arch Linux powering PINE64 tablets, Ubuntu offering live patching on HWE kernels, gaining compression on ex4 |
| • Issue 1014 (2023-04-10): Quick looks at carbonOS, LibreELEC, and Kodi, Mint polishes themes, Fedora rolls out more encryption plans, elementary OS improves sideloading experience |
| • Issue 1013 (2023-04-03): Alpine Linux 3.17.2, printing manual pages, Ubuntu Cinnamon becomes official flavour, Endeavour OS plans for new installer, HardenedBSD plans for outage |
| • Issue 1012 (2023-03-27): siduction 22.1.1, protecting privacy from proprietary applications, GNOME team shares new features, Canonical updates Ubuntu 20.04, politics and the Linux kernel |
| • Issue 1011 (2023-03-20): Serpent OS, Security Onion 2.3, Gentoo Live, replacing the scp utility, openSUSE sees surge in downloads, Debian runs elction with one candidate |
| • Issue 1010 (2023-03-13): blendOS 2023.01.26, keeping track of which files a package installs, improved network widget coming to elementary OS, Vanilla OS changes its base distro |
| • Issue 1009 (2023-03-06): Nemo Mobile and the PinePhone, matching the performance of one distro on another, Linux Mint adds performance boosts and security, custom Ubuntu and Debian builds through Cubic |
| • Issue 1008 (2023-02-27): elementary OS 7.0, the benefits of boot environments, Purism offers lapdock for Librem 5, Ubuntu community flavours directed to drop Flatpak support for Snap |
| • Issue 1007 (2023-02-20): helloSystem 0.8.0, underrated distributions, Solus team working to repair their website, SUSE testing Micro edition, Canonical publishes real-time edition of Ubuntu 22.04 |
| • Issue 1006 (2023-02-13): Playing music with UBports on a PinePhone, quick command line and shell scripting questions, Fedora expands third-party software support, Vanilla OS adds Nix package support |
| • Issue 1005 (2023-02-06): NuTyX 22.12.0 running CDE, user identification numbers, Pop!_OS shares COSMIC progress, Mint makes keyboard and mouse options more accessible |
| • Issue 1004 (2023-01-30): OpenMandriva ROME, checking the health of a disk, Debian adopting OpenSnitch, FreeBSD publishes status report |
| • Issue 1003 (2023-01-23): risiOS 37, mixing package types, Fedora seeks installer feedback, Sparky offers easier persistence with USB writer |
| • Issue 1002 (2023-01-16): Vanilla OS 22.10, Nobara Project 37, verifying torrent downloads, Haiku improvements, HAMMER2 being ports to NetBSD |
| • Issue 1001 (2023-01-09): Arch Linux, Ubuntu tests new system installer, porting KDE software to OpenBSD, verifying files copied properly |
| • Issue 1000 (2023-01-02): Our favourite projects of all time, Fedora trying out unified kernel images and trying to speed up shutdowns, Slackware tests new kernel, detecting what is taking up disk space |
| • Issue 999 (2022-12-19): Favourite distributions of 2022, Fedora plans Budgie spin, UBports releasing security patches for 16.04, Haiku working on new ports |
| • Issue 998 (2022-12-12): OpenBSD 7.2, Asahi Linux enages video hardware acceleration on Apple ARM computers, Manjaro drops proprietary codecs from Mesa package |
| • Issue 997 (2022-12-05): CachyOS 221023 and AgarimOS, working with filenames which contain special characters, elementary OS team fixes delta updates, new features coming to Xfce |
| • Issue 996 (2022-11-28): Void 20221001, remotely shutting down a machine, complex aliases, Fedora tests new web-based installer, Refox OS running on real hardware |
| • Issue 995 (2022-11-21): Fedora 37, swap files vs swap partitions, Unity running on Arch, UBports seeks testers, Murena adds support for more devices |
| • Issue 994 (2022-11-14): Redcore Linux 2201, changing the terminal font size, Fedora plans Phosh spin, openSUSE publishes on-line manual pages, disabling Snap auto-updates |
| • Full list of all issues |
| Star Labs |
Star Labs - Laptops built for Linux.
View our range including the highly anticipated StarFighter. Available with coreboot open-source firmware and a choice of Ubuntu, elementary, Manjaro and more. Visit Star Labs for information, to buy and get support.
|
| Shells.com |
Your own personal Linux computer in the cloud, available on any device. Supported operating systems include Android, Debian, Fedora, KDE neon, Kubuntu, Linux Mint, Manjaro and Ubuntu, ready in minutes.
Starting at US$4.95 per month, 7-day money-back guarantee
|
| Random Distribution | 
Slavix
Slavix was an operating system based on Debian, KNOPPIX and Morphix. Its purpose was to make it easy for anyone to switch to GNU/Linux and start using free (as in freedom) software. Slavix was oriented towards a home computer user. It was a live CD system so it was possible to run it CD-ROM without having to install anything to a hard drive. All you need to do was burn the Slavix image file to a CD, put it in your CD-ROM and reboot. It will start up, auto configure itself and in about 3 - 5 minutes it's ready to use. Slavix will not touch your hard drive or mess with you data. A hard disk installer was included and it was fairly easy to use.
Status: Discontinued
|
| TUXEDO |
TUXEDO Computers - Linux Hardware in a tailor made suite
Choose from a wide range of laptops and PCs in various sizes and shapes at TUXEDOComputers.com. Every machine comes pre-installed and ready-to-run with Linux. Full 24 months of warranty and lifetime support included!
Learn more about our full service package and all benefits from buying at TUXEDO.
|
| Star Labs |
Star Labs - Laptops built for Linux.
View our range including the highly anticipated StarFighter. Available with coreboot open-source firmware and a choice of Ubuntu, elementary, Manjaro and more. Visit Star Labs for information, to buy and get support.
|
|
• 
• 
• 
• 
• 
• 
• 
