More #inxi / #pinxi CPU issues, it looks like #fedora / #rhel have changed a default standard path in /sys for unknown reasons, thus breaking inxi cpu speed collection. This tripped need to do more refactors, this time to the fake cpu data debugger logic, it was not complete.
Also, a new codeberg issue pointed out that in many #Linux I can get basic RAM/RAM array data from udevadm, which appears to dump some dmi data into itself, available to user.
On the surface, the current #Linux distribution model (where distros package everything, from the kernel to the apps) seems fine.
But it's pretty broken, and it's holding the Linux desktop back, which is why distributions like #Ubuntu or #Fedora (and a lot more), are moving away from it, and replacing packages with Snaps and Flatpaks for graphical applications.
Here's my opinion on this, trying to explain why exactly this change needs to happen:
For users of any operating system, not just #Linux, what might keep you from trying/running an #immutable#Fedora desktop? If you are already running one, why did you choose it?
Why do we still live in a world where I can't independently configure my laptop display and external monitor's scaling (100% and 150% respectively) in #Linux? Or is this just an Ubuntu/Kubuntu problem?
Under X11 both displays sync their scaling settings (awful experience when you have a 4K panel). And with Wayland both displays end up blurry, even after a reboot.
I'm using the HP Dev One.
Are there easy workarounds or should I finally make the permanent switch to #fedora?
Firefox with its stock look, proper rounded window corners and actual Wayland support feels like jumping 5 years ahead of how it's shipped by default currently.
Hello everyone, so at my new job I'll get a MacBook snd until #AsahiLinux supports the security processor I will be a good girl and use #macOS. For someone coming from a setup mixing #ArchLinux, #Fedora#Silverblue / #CoreOS, even some #NixOS and does weird stuff with #podman sometimes: Are there some general recommendations from other #Linux exiles (I use vanilla #GNOME nowadays mostly, so maybe not too much lol?)
I currently plan to use the mac as mostly a shiny looking physical terminal + some vscode/vi, that should be mostly trivial. As such I'm mostly worried about things like a proper keyboard layout (I use us altgr-intl, caps mapped to ctrl, tab to esc).
Otherwise I'm thinking of grabbing #Firefox and activating Lockdown Mode. I've seen nix-home and will try setting that up for day-to-day tasks/tools.
Coming from Evolution, is Apple Mail decent? Any other "classic" GNOME tool I'd miss? Currently looking for trustworthy replacements for Nick's YT downloader, Warp (Wormhole GUI), Frog (OCR tool), Obfuscate (picture obfuscator/censoring tool), Characters (searching through Unicode symbols/emoji). Anything else I may take for granted but is different? ¹
¹ I already know the cli differences w.r.t. bsd based tools, but my personal scripts are mostly posix/ksh8x compliant anyway :D
I'm on #Fedora#Silverblue 40, and I'm now seeing a lot of "No video with supported format and MIME type found" errors.
I don't have mozilla-openh264 installed, so I guess that might make sense? Let's fix that...
# rpm-ostree install mozilla-openh264<br></br>...<br></br>error: Could not depsolve transaction; 1 problem detected:<br></br> Problem: package noopenh264-0.1.0~openh264_2.4.0-1.fc40.x86_64 from @System conflicts with openh264 provided by openh264-2.4.0-2.fc40.x86_64 from fedora-cisco-openh264<br></br> - package openh264-2.4.0-2.fc40.x86_64 from fedora-cisco-openh264 obsoletes noopenh264 < 1:0 provided by noopenh264-0.1.0~openh264_2.4.0-1.fc40.x86_64 from @System<br></br> - package mozilla-openh264-2.4.0-2.fc40.x86_64 from fedora-cisco-openh264 requires openh264(x86-64) = 2.4.0-2.fc40, but none of the providers can be installed<br></br> - conflicting requests<br></br># rpm -qa | grep noopenh264<br></br>noopenh264-0.1.0~openh264_2.4.0-1.fc40.x86_64<br></br># rpm-ostree install --uninstall noopenh264 mozilla-openh264<br></br>error: Package/capability 'noopenh264' is not currently requested<br></br>
There's clearly something I don't understand here. I don't know how noopenh264 is installed but not requested and still causes a conflict. I must be alone in having this problem based on lack of bugs that I can find in RH's bugzilla.
I don't think I saw this problem on Silverblue 39, but I was using that for only a few days before rebasing on 40, and was previously on my "classic" Fedora 39 installation where it definitely wasn't showing up with the rpmfusion packages installed.
My response to @fedora’s proposal to implement opt-out data collection in Fedora, which was marked as hidden and “flagged as inappropriate: the community feels it is offensive, abusive, to be hateful conduct or a violation of our community guidelines.”
By popular demand, I took a look at #Nobara, the gaming focused derivative of #Fedora.
I compared the default experience, various ease of use tweaks, controller support, gaming performance, and highlighted the major differences, after installing both distros on the same device.
So, is Nobara truly better than Fedora for gaming? Let’s see!
So I recently ran across this post and thread by @vwbusguy, and I would like to try to address some of the questions/misconceptions/etc that come up in the thread.
If you have questions, please, ask. What we do with #Kalpa isn't identical to what #Fedora does with their #AtomicDesktops, but many of the concepts for the end user are going to be similar/the same.
It's sad and unfortunate that a number of #Fedora people have chosen to block or unfollow me over speaking about recent RHEL stuff, including some I have great respect for. I understand that tensions are high, but I hope bridges can be rebuilt in due time.
Annoyed by having to put #sudo in front on #dmesg[1]?
Then use this instead[2]:
$ journalctl -k
It should work if the user executing this is a member of the groups "systemd-journal", "adm", or "wheel".
[1] which is the case if CONFIG_SECURITY_DMESG_RESTRICT is turned on in your #Linux#kernel's .config – which #Fedora recently switched on, something many other distros did already a while ago.
[2] works for the common case, for some fancier stuff you might still need dmesg #LinuxKernel
Something I don’t love about Silverblue with GNOME as it is today is that there is little visibility into ongoing OS upgrades, e.g. when rpm-ostree is pulling down a new OS deployment.
And worse, unless I am misunderstanding what is happening, it seems to also make GNOME Software seem to hang when in fact it is doing important (albeit what should be background) work.