Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
Why are Fedora / RHEL / AlmaLinux so broken? (Screenshots)
Why are Fedora / RHEL / AlmaLinux so broken? (Screenshots)
This is probably preaching to the choir, but why are Fedora / RHEL / AlmaLinux so broken?
I decided to try them out in VirtualBox after many years of not using them. Results so far:
Fedora 34, repeatedly crashes during the "welcome" screen. This is where Gnome 4 asks you to set up your user name and details. Maybe it's some kind of Wayland/Gnome4 incompatibility with VirtualBox?
For AlmaLinux (a CentOS replacement), based on RHEL 8: I can't even install Okular. I tried doing "yum update" and rebooting, but the results are the same.
Installing from the "software center" also gives an error, but doesn't tell you what it is (clicking on the message does nothing):
Not sure if this is RedHat's fault, or AlmaLinux's. AlmaLinux is supposed to be binary-compatible (or identical), like CentOS and Rocky Linux.
Also, "yum update" asks what sounds like unreasonable questions:
Is this OK? How am I supposed to know? Isn't the system keeping track of trusted certificates and all that jazz?
Was I just very unlucky? Using Fedora / RHEL / AlmaLinux incorrectly due to inexperience?
I decided to try them out in VirtualBox after many years of not using them. Results so far:
Fedora 34, repeatedly crashes during the "welcome" screen. This is where Gnome 4 asks you to set up your user name and details. Maybe it's some kind of Wayland/Gnome4 incompatibility with VirtualBox?
For AlmaLinux (a CentOS replacement), based on RHEL 8: I can't even install Okular. I tried doing "yum update" and rebooting, but the results are the same.
Installing from the "software center" also gives an error, but doesn't tell you what it is (clicking on the message does nothing):
Not sure if this is RedHat's fault, or AlmaLinux's. AlmaLinux is supposed to be binary-compatible (or identical), like CentOS and Rocky Linux.
Also, "yum update" asks what sounds like unreasonable questions:
Is this OK? How am I supposed to know? Isn't the system keeping track of trusted certificates and all that jazz?
Was I just very unlucky? Using Fedora / RHEL / AlmaLinux incorrectly due to inexperience?
- Northpoint
- Posts: 88
- Joined: 2020-12-19 10:51
- Location: USA
- Has thanked: 48 times
- Been thanked: 13 times
Re: Why are Fedora / RHEL / AlmaLinux so broken? (Screenshots)
The [y/N] is just asking if its alright to import a key. Just choose 'y'.
The other errors are from unmet dependencies. This happens to me a lot too. I will just search around and find the missing package - in your case libpoppler-qt5 . You might run into a situation where you need qt5 also. I dont know. Sometimes this can lead you down a rabbit hole of unmet dependencies and conflicts. It just happens.
The other errors are from unmet dependencies. This happens to me a lot too. I will just search around and find the missing package - in your case libpoppler-qt5 . You might run into a situation where you need qt5 also. I dont know. Sometimes this can lead you down a rabbit hole of unmet dependencies and conflicts. It just happens.
Get your linux on.
Re: Why are Fedora / RHEL / AlmaLinux so broken? (Screenshots)
Couple different things are going on for you here, but there is no package per se for Okular installable with YUM thus the epel designation. You have to install snapd and then install the Okular snap. There are many packages now listed as epels because of dependency problems, but many can be installed as snaps. Yuck.
TC
TC
You can't believe your eyes if your imagination is out of focus.
Re: Why are Fedora / RHEL / AlmaLinux so broken? (Screenshots)
I did, because it was in a throwaway VM, but otherwise, how do you know "y" is safe? And if you can know this, why doesn't yum?Northpoint wrote: ↑2021-10-20 17:34 The [y/N] is just asking if its alright to import a key. Just choose 'y'.
I remember this dependency hell from using RedHat a bit a very long time ago, but I thought yum was supposed to fix that.The other errors are from unmet dependencies. This happens to me a lot too. I will just search around and find the missing package - in your case libpoppler-qt5 . You might run into a situation where you need qt5 also. I dont know. Sometimes this can lead you down a rabbit hole of unmet dependencies and conflicts. It just happens.
Re: Why are Fedora / RHEL / AlmaLinux so broken? (Screenshots)
If snaps are more secure, I can see how running Okular as a snap is a good idea. People use it to view PDFs they downloaded from the web. It's essentially a browser from the security point of view.trinidad wrote: ↑2021-10-20 18:10 Couple different things are going on for you here, but there is no package per se for Okular installable with YUM thus the epel designation. You have to install snapd and then install the Okular snap. There are many packages now listed as epels because of dependency problems, but many can be installed as snaps. Yuck.
But as a naive GUI user, I'm never prompted to enable EPEL or whatever. I just get an uninformative "error".
- sunrat
- Administrator
- Posts: 6414
- Joined: 2006-08-29 09:12
- Location: Melbourne, Australia
- Has thanked: 116 times
- Been thanked: 462 times
Re: Why are Fedora / RHEL / AlmaLinux so broken? (Screenshots)
Snaps are not secure at all. There is little or no auditing of apps in the snap store and there have been several instances of malware being installed from there.
Okular is available in Debian repositories. For Debian.
You would get more interest in discussing Fedora on Fedora forums.
“ computer users can be divided into 2 categories:
Those who have lost data
...and those who have not lost data YET ” Remember to BACKUP!
Those who have lost data
...and those who have not lost data YET ” Remember to BACKUP!
Re: Why are Fedora / RHEL / AlmaLinux so broken? (Screenshots)
I'm no expert at this, but snapd uses the AppArmor kernel module to sandbox the apps somehow. Google Chrome also uses some kind of sandboxing internally, as an extra security layer. So running Okular as a snap is a bit like running Chrome in this sense.
- Northpoint
- Posts: 88
- Joined: 2020-12-19 10:51
- Location: USA
- Has thanked: 48 times
- Been thanked: 13 times
Re: Why are Fedora / RHEL / AlmaLinux so broken? (Screenshots)
Yum is just an installer. It does not make your decisions for you and it shouldnt. Its giving you a choice which is a good thing. Unlike something line - ahem... Microsoft.I did, because it was in a throwaway VM, but otherwise, how do you know "y" is safe? And if you can know this, why doesn't yum?
An installer cannot install something that is not there.I remember this dependency hell from using RedHat a bit a very long time ago, but I thought yum was supposed to fix that.
I understand your frustration. I have ran into software installs where things are missing. I do my best to install the missing dependencies myself. I do a search for the dependency and will do a manual install if need be. I also search for an existing article on how to install the software on the flavor of linux.
As @sunrat said - Check with Redhat or Fedora.
Get your linux on.
Re: Why are Fedora / RHEL / AlmaLinux so broken? (Screenshots)
Informed choice is good. But this is one is uninformed and on top of that, as far as I can tell, useless.Northpoint wrote: ↑2021-10-21 11:05Yum is just an installer. It does not make your decisions for you and it shouldnt. Its giving you a choice which is a good thing. Unlike something line - ahem... Microsoft.I did, because it was in a throwaway VM, but otherwise, how do you know "y" is safe? And if you can know this, why doesn't yum?
Do you want your software to bombard you with questions like:
It's giving you a choice, see?The next bit I'm about to write to a file is 1.
Is this ok [y/N]:
- Northpoint
- Posts: 88
- Joined: 2020-12-19 10:51
- Location: USA
- Has thanked: 48 times
- Been thanked: 13 times
Re: Why are Fedora / RHEL / AlmaLinux so broken? (Screenshots)
@maxb Having one question to accept the repo does not really qualify as "bombarded". I understand that you "do not understand the question" and thus is useless to you. However, Look at it this way - Now you know. So, It should not be useless to you any more.
Look at it as a learning opportunity. Not as a problem that you have to face. If your really against something like that then next time add a "-y" to the end to automatically answer yes.
I do believe like this:
To me this is not a big deal to accept a key.
Look at it as a learning opportunity. Not as a problem that you have to face. If your really against something like that then next time add a "-y" to the end to automatically answer yes.
I do believe like this:
Code: Select all
sudo apt install (software name) -y
Get your linux on.
Re: Why are Fedora / RHEL / AlmaLinux so broken? (Screenshots)
It's not asking me to accept a repo. It's asking me to accept a GPG signature 0x2F86D6A1. Maybe it belongs to RedHat (in which case, why are they asking). Maybe the key changed suspiciously from what it was supposed to be, which prompted this question. The user has no idea what's going on.Northpoint wrote: ↑2021-10-21 18:07 @maxb Having one question to accept the repo does not really qualify as "bombarded". I understand that you "do not understand the question" and thus is useless to you. However, Look at it this way - Now you know. So, It should not be useless to you any more.
-
- Posts: 932
- Joined: 2020-05-03 14:16
- Has thanked: 7 times
- Been thanked: 65 times
Re: Why are Fedora / RHEL / AlmaLinux so broken? (Screenshots)
+1
Moreover, the proclaimed "safety" which the snaps are supposed to give to the end users is nothing but a lie:
*every single application* / process on linux is running in its own virtual machine created on demand by the linux kernel - snaps are just slower to load, and less secure - because they are using untested/non-shared/experimental libs (and what's rather funny - there is no real need for this - because all the standard libs and all the libs which are using libtool are by definition backward-compatible).
Bill Gates: "(...) In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating system."
The_full_story and Nothing_have_changed
The_full_story and Nothing_have_changed
Re: Why are Fedora / RHEL / AlmaLinux so broken? (Screenshots)
There are different kinds of "virtual machines", and if the ones the OS creates for every process were safe enough to run untrusted code in them, there wouldn't be any need for sandboxes like, say, "firejail".LE_746F6D617A7A69 wrote: ↑2021-10-21 20:57+1
Moreover, the proclaimed "safety" which the snaps are supposed to give to the end users is nothing but a lie:
*every single application* / process on linux is running in its own virtual machine created on demand by the linux kernel - snaps are just slower to load, and less secure - because they are using untested/non-shared/experimental libs (and what's rather funny - there is no real need for this - because all the standard libs and all the libs which are using libtool are by definition backward-compatible).
https://man7.org/linux/man-pages/man1/firejail.1.html
-
- Posts: 932
- Joined: 2020-05-03 14:16
- Has thanked: 7 times
- Been thanked: 65 times
Re: Why are Fedora / RHEL / AlmaLinux so broken? (Screenshots)
You shouldn't use untrusted software in the first place.
Firejail doesn't do any magic on its own - it uses virtualization technologies offered by the Linux kernel.
You can f.e. use schroot as well.
The default VM for user processes is safe enough to protect the OS and isolate applications from each other.
This is 100% sufficient for normal applications (i.e. from the repository or compiled by Yourself from source), and it does not cause performance loss.
If You want to shoot Yourself in a foot, then no kind of sanboxing will help.
Firejail doesn't do any magic on its own - it uses virtualization technologies offered by the Linux kernel.
You can f.e. use schroot as well.
The default VM for user processes is safe enough to protect the OS and isolate applications from each other.
This is 100% sufficient for normal applications (i.e. from the repository or compiled by Yourself from source), and it does not cause performance loss.
If You want to shoot Yourself in a foot, then no kind of sanboxing will help.
Bill Gates: "(...) In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating system."
The_full_story and Nothing_have_changed
The_full_story and Nothing_have_changed
Re: Why are Fedora / RHEL / AlmaLinux so broken? (Screenshots)
What you have established there is that, some software is running in a sandbox once installed, not that the software has been security audited.
It's also from Canonical, which means the CLA... and the server side is proprietary. So more than a few reasons to avoid...
Re: Why are Fedora / RHEL / AlmaLinux so broken? (Screenshots)
First, I'm not advocating the use of snapd, but
People can say "The OS allows each process to run in its own VM" and they can also say "I'm running Windows in a VM". But guess what? These are different "VMs"! The former is "virtual memory", and the latter is "virtual machine".
This is probably what led to all this confusion of "per-process virtual machines" that are safe:
Every time you open a random web site, assuming you have JS enabled, you are running untrusted software on your machine, and ...
I've been writing code, including C++, since last century, so allow me to clarify a few things.LE_746F6D617A7A69 wrote: ↑2021-10-22 14:41 The default VM for user processes is safe enough to protect the OS and isolate applications from each other.
This is 100% sufficient for normal applications (i.e. from the repository or compiled by Yourself from source), and it does not cause performance loss.
People can say "The OS allows each process to run in its own VM" and they can also say "I'm running Windows in a VM". But guess what? These are different "VMs"! The former is "virtual memory", and the latter is "virtual machine".
This is probably what led to all this confusion of "per-process virtual machines" that are safe:
And regardless of what you call these "VMs", they are very different. The virtual memory, that each process gets, offers very little protection against this process messing you up (like deleting or uploading all your files, planting spyware, etc.).Moreover, the proclaimed "safety" which the snaps are supposed to give to the end users is nothing but a lie:
*every single application* / process on linux is running in its own virtual machine created on demand by the linux kernel - snaps are just slower to load, and less secure - because they are using untested/non-shared/experimental libs (and what's rather funny - there is no real need for this - because all the standard libs and all the libs which are using libtool are by definition backward-compatible).
Code that's vulnerable and that's running on untrusted input (like a document someone sent you) can become as good as "untrusted". Doesn't matter if you trust the person who wrote the code.You shouldn't use untrusted software in the first place.
Every time you open a random web site, assuming you have JS enabled, you are running untrusted software on your machine, and ...
... it's the sandboxing in, say, Chrome that helps keep you safe (If Chrome were perfect, it wouldn't need sandboxing, but it gets 200+ CVEs per year, and these are just the issues that people find and disclose publicly)If You want to shoot Yourself in a foot, then no kind of sanboxing will help.
-
- Posts: 932
- Joined: 2020-05-03 14:16
- Has thanked: 7 times
- Been thanked: 65 times
Re: Why are Fedora / RHEL / AlmaLinux so broken? (Screenshots)
Let's imagine a perfect sanboxing: 100% isolation: it is possible -> just run the untrusted application on a separete physical machine, dedicated for this single application only -> Are You safe?
Obviously NOT.
By interacting with the application, You are becoming part of the game, wheter You like it or not.
Real life example: some closed source WEB browser can spy on You, intercepting all your logins and passwords, posts, pictures that You're uploading to "trusted" sites, Your mail contacts, etc - lots of other possibilities.
NO KIND OF SANBOXING CAN PREVENT THIS -> because You are letting untrusted application to process Your data.
Virtual Machines are also useless in such case, and that's only single example -> the same applies f.e. to WEB services that are spying on You - even if You use perfectly safe, sandboxed web-browser, it won't help.
Regarding JavaScript, You are right - that's why NoScript is a must-have extension for anyone who cares about his privacy.
Sandboxing gives an illusion of safety - nothing more.
From the OS point of view, process address space virtualization is used mainly to allow the OS to recover from application crashes, but unlike in case of snaps, the virtualization doesn't break sharing of libraries.
EDIT:
This is off-topic in an off-topic thread, and perhaps it would be better to start another topic, dedicated to safety of Operating Systems, but unless we have one, I think it would be reasonable to add the following warnings:
1. Snaps can include the core libc library, what allows to implement a "return to C" attacks -> allowing direct calls to the kernel, and bypassing all the security measures implemented in the system.
2. "nasty" programs can "escape" from Virtual Machines: search for "Blue Pill" and "Red Pill" cases. (terminology from Matrix movie)
/EDID
Obviously NOT.
By interacting with the application, You are becoming part of the game, wheter You like it or not.
Real life example: some closed source WEB browser can spy on You, intercepting all your logins and passwords, posts, pictures that You're uploading to "trusted" sites, Your mail contacts, etc - lots of other possibilities.
NO KIND OF SANBOXING CAN PREVENT THIS -> because You are letting untrusted application to process Your data.
Virtual Machines are also useless in such case, and that's only single example -> the same applies f.e. to WEB services that are spying on You - even if You use perfectly safe, sandboxed web-browser, it won't help.
Regarding JavaScript, You are right - that's why NoScript is a must-have extension for anyone who cares about his privacy.
Uhm, but even perfectly sandboxed process can fill up a directory which is allowed to be used by such process or it can overload the CPU causing performance loss in other applications, or it can assist in attacks on the TCP stack ..
Sandboxing gives an illusion of safety - nothing more.
From the OS point of view, process address space virtualization is used mainly to allow the OS to recover from application crashes, but unlike in case of snaps, the virtualization doesn't break sharing of libraries.
EDIT:
This is off-topic in an off-topic thread, and perhaps it would be better to start another topic, dedicated to safety of Operating Systems, but unless we have one, I think it would be reasonable to add the following warnings:
1. Snaps can include the core libc library, what allows to implement a "return to C" attacks -> allowing direct calls to the kernel, and bypassing all the security measures implemented in the system.
2. "nasty" programs can "escape" from Virtual Machines: search for "Blue Pill" and "Red Pill" cases. (terminology from Matrix movie)
/EDID
Bill Gates: "(...) In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating system."
The_full_story and Nothing_have_changed
The_full_story and Nothing_have_changed