I wouldn’t use CentOS for private/ desktop stuff personally.
Do you really need its features? Afaik, the “security” features you mentioned are mainly for server use. At least that’s what I have in my mind right now when I researched possible candidates for my home server some time ago.
I think sticking with a “home use” distro would suit you better.
There are a few options as suggestions:
Stay on Kinoite
==================
There’s barely any configuration drift compared to the mutable Fedora. Therefore, it should be less buggy.
Fedora Atomic KDE gave me the best Plasma experience yet. I often tested KDE (I’m a Gnome guy myself, but here and there hop to KDE for a few months) and on most installs on other distros like Suse/ Workstation/ Debian, it got more and more buggy after a few weeks due to updates and tweaks.
So, bugfixes often didn’t apply to my system, only the default one or the install from the devs.
I find Fedora’s release schedule to be the perfect sweetspot between reliable, stable and up to date.
If you’re really impatient, you can always switch to the nightly builds (on Atomic), which are more bug prone and rolling. Maybe, Plasma will be stable enough before it hits the official image. But you should keep at least one stable image in your bootloader.
Debian and Leap
==================
Debian “just” got it’s new release and will be stale for the next years. BUT, many of those Plasma 6 bug fixes will be backported to 5.27. Still, many of the QOL-changes are 6-exclusive.
OpenSuse Leap also gives you a great KDE experience and is pretty similar to Debian, both in release schedule and when the last big update hit.
Distrobox
============
You can use an Arch/ Tumbleweed container on Debian/ slow release distro to get all the newest KDE stuff on the outside and keep your stable base beneath.
Why? Because, in my experience, Plasma only gets more refined each update. As long as there aren’t any new big features, there are about hundred bugs resolved weekly.
Or, you can do the opposite. Use something newer, like TW, Slowroll, Sid(uction) or Arch, to get the newest software under the hood, and use the Debian repo to get a stable DE.
Just what you prefer.
In your case, I’d settle with Fedora (mutable or Atomic, in your case the Kinoite version, as I’d prefer that one too), and just don’t upgrade to the newest version.
The older version is always supported for a year or two, and you don’t have to upgrade each release. The bug fixes always get backported if possible.
Thanks! Yes its a shame that Debian (and Leap?) Will not have Plasma6 in like 6 months where stable release would fit perfectly.
My experience is the same, on Manjaro Plasma was way better than on Kubuntu and Manjaro convinced me of Plasma. Fedora is a sweet spot and staying with F39 for a while (even though I will probably switch to F40 right away as Plasma6 has sooo many bug fixes I personally reported) could work.
You mean a rootful Distrobox with a DE in it? I have to try that out, sounds crazy. Would need a seperate home if that is possible, as I dont want to have messed up dotfiles.
As pointed out, in Windows defence, it’s actually faster where it matters. And none of it is going to matter in adoption until every thing is supported 1-1.
The only reason we’re behind on adoption vs Windows as this point is that people who write software for Windows, don’t do it for GNU/Linux, or even publish specs in the case of drivers.
It’s not the OSes problem. It hasn’t been for a long time. It’s stubborn developers (mainly corporations like Broadcom, Nvidia and Epic). We shouldn’t need to write compatibility layers for completely foreign software to run, or write drivers to drive a megacorporation’s hardware, and those are both a monumental task, but the community continues to achieve it anyways.
A lot has been done and continues to be done by the community, and that’s great, but the real problem is the corporations who refuse to invest a little bit of their time in GNU/Linux support (and those who have an irrational vendetta against it).
Causes are a part of the reality. And when people go online and complain about how “lInUX SuXxx” because their proprietary Nvidia drivers didn’t work, and blame the OS instead of the company who is meant to be providing proper support for their devices or at least documentation for other developers to use, it plants the idea in people’s minds that the OS itself is simply inferior, which has connotations of it just being a bad system. Instead of “it will work perfectly when drivers are actually released by the manufacturer”. It tarnishes it’s reputation even after that particular device gains support, and that is another reason why adoption is low.
Hell, nVidia was actively working against having a working opensource driver reverse engineered by Nouveau. Linux is a thorn in their side and the only reason they somewhat support it today is that GPU compute works so much better on Linux.
The article didn’t mention this, but would disabling the UEFI logo in the boot screen mitigate the vulnerability until proper patches get rolled out? (Or honestly at this point, I’d keep it disabled even after it’s patched in case they didn’t patch it right. UEFI’s are all proprietary so it’s not like you can check.) Since the vulnerability is in the image parser, would bypassing that be enough?
I’ve never been a fan of the UEFI logo inserting itself into the boot screen. It’s basically just an advertisement for the hardware vendor because they’re jealous of the OS having the spotlight. And it’s an ad that, like so many other ads before it, screws over the security and privacy of the advertisee because fuck you that’s why.
I don’t know. It looks more aesthetically consistent. Your computer has to display something. Average users would be scared if it dumped logs on the display. so the vendor logo makes sense. It COULD just say loading, but this is a bit pedantic I think.
With UEFI, it goes “Motherboard Logo -> Motherboard Logo”
Sure, it’s more consistent, but the alternative is not user unfriendly, the only people it’s unfriendly to is the marketing wankers at Dell, Lenovo, Acer, etc.
When it comes to security, particularly at boot time, fuck the user. Users don’t interact with devices at boot time so it doesn’t matter if it shows a blank screen, a mile of logs or a screaming clown penis. If it was up to users no device or service would have a password or security of any kind, and every byte of information about your life would be owned by 'The Cloud." Let the marketing wanks insert their logo into the Windows boot process,
I want to insert my own logo into the boot process, and I want these ducking vendors to properly validate and assess their mother ducking software. But nooo, penetration tests and any remediations are too expensive for these pieces of bit. Why do it when you can just stick your dick in everyone’s face, right?
I just wish they would use another name for it, it’s linux here no need to copy windows slang! Or use another color! (I hope they’ll update it to make it a customizable color)
Fun fact: The Windows BSOD colour was as easy as adding a couple of lines to a .INI file for a long time. Then, as they tend to do, they made it more difficult, but it was still possible. Third party tools were written to do the work.
Very recent MS Windows I have no idea about. My search-fu is failing me.
Anyway, my point is that the "two lines in a config file" method would be nice.
Knowing systemd though, it'll be "send some kind of message into a /proc pseudo-file", or a sub-sub-sub-command of one of the many systemd* commands which ultimately does the same thing.
I love this! Not only for the comedic value, but throwing kernel oopses on-screen when they can’t be easily captured when unprepared would be of great help in solving system problems. Unlike the cryptic messages Windows displays, Linux kernel messages are quite useful.
Just use rsync -va (possibly with --chown if you want user/group to be different at the destination and with --delete if you want removed files to be deleted) to continue the copy operation, it automatically takes care of figuring out which files still need to be copied and which are already there.
The default quick check algorithm of rsync is not safe for this. It only checks filesize and modification time to determine if files are equal. After a b0rked copy, these are not to be trusted.
You should add the -c flag so that files are properly checksummed, unfortunately if you have slow storage on either end, this often negates the speed advantage of rsync.
My memory of the cp command is that attributes such as file times were transferred at the last step. I think this would make rsync safe in most situations where a system crash wasn’t involved.
True if the initial state is unknown but if you do your initial copy and all the later syncs with rsync it is not really necessary since rsync puts the partial files in a temporary location (there are same parameters to control the details of that too).
So I don’t get it, I have my entire boot image in a signed EFI binary, the logo is in there as well. I don’t think I’m susceptible to this, right? I don’t think systemd-boot or the kernel reads an unsigned logo file anywhere. (Using secure boot)
Depending on how the UEFI is configured, a simple copy/paste command, executed either by the malicious image or with physical access, is in many cases all that’s required to place the malicious image into what’s known as the ESP, short for EFI System Partition, a region of the hard drive that stores boot loaders, kernel images, and any device drivers, system utilities, or other data files needed before the main OS loads.
Right, I know EFI images are stored in the EFI partition, but with secure boot, only signed images can be executed, so they’d need to steal someone’s signing key to do this.
but LXDE should effectively be considered “end of life”, the developer is in the process of porting everything over to Qt and working on releases of LXQt
with that, for a full DE – Xfce if you like GTK, LXQt if you like Qt
or a minimal setup with a WM plus utilities (like Openbox or one of the large selection of tiling window managers)
along those lines though, there are still a LOT of lightweight Linux distros to choose from
Crunchbangplusplus or BunsenLabs – successors to Crunchbang Linux – usually just Openbox WM and a few utils rather than a full DE
plain old Debian stable – proprietary drivers are now part of the installer, no more hunting for a special ISO – can choose your DE or WM during install
linux
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.