3,603 karma · joined October 4, 2018
https://omenos.dev/
Online Accounts:
Git{Hub,Lab}, Codeberg, SourceHut: @omenos
Bluesky: @omenos.dev
Matrix: @mroche:fedora.im
Mastodon: @omenos@fosstodon.org
You still have time to figure out what to do, but you'll need to choose sooner than later.
Available platforms like Codeberg provide the option to sign in/register with GitHub and GitLab auth, so needing "yet another account" has become a much weaker argument.
So a few weeks ago I updated to Fedora 41. (Updating from N-2 -> N is supposed to be fully supported)
Correct, and I do believe F39 -> F41 was tested, but every system will be a little bit different.
I wasn't surprised that it broke my nvidia driver's dkms integration - I don't expect any distro to test their integration of the market leader GPU manufacturer.
Fedora actually does test this. What driver installation method are you using? Unless you are using NVIDIA GRID for vGPU or need to use a very specific version of the generic Linux driver, use RPM Fusion's akmod-nvidia package[0]. Normal DKMS via NVIDIA's modularity CUDA repositories or the binary installer can be fraught with issues that users don't deserve. Rather than just installing the kmods directly, an akmod package will build an RPM for the modules and install that. You'll know well in advance if there's a problem before you reboot, nor have to twiddle your thumbs during the upgrade transactions. Just give the system an extra minute after running a kernel update before rebooting (watching "ps aux" for "dnf", "kmod", and "rpm" helps). Several system configurations regarding module parameters and initramfs boot options are included as well.
I finally did this today (I have a GTX 1070), but configuring my kernel parameters[1] to disable NVIDIA's fbdev allows me to once again have alternate console TTYs. Despite being an experimental option, it is enabled by default in newer drivers and it conflicts with another framebuffer. For the past few Fedora releases since it was flipped on I've had to use a second device to SSH to my system after the version upgrade to gracefully reboot once the driver module package rebuilt. The akmod rebuild trigger doesn't stall the offline upgrade reboot, so the driver isn't prepared in time for first boot. My standard practice is configuring my system to the multi-user target before issuing an offline version upgrade, then switching back after.
the system was suspended. When I wake it up, the screen is also locked. That was weird, as I have disabled all power mgment features, and I have also passwordless autologin on this machine. Then looking at some of the logs, it turned out that xdg-desktop-portal segfaulted in the middle of the night, which in turn killed all user sessions and processes and logged me out. And then it ignored my powermgmt settings, and sent the machine to sleep.
That is definitely a new one to me. In addition to your searching, did you happen to follow through with Fedora's problem reporting checklist[3]? It's not a mandatory step, but it can be incredibly helpful having these issues documented and brought to engineering's attention.
[0]: https://rpmfusion.org/Howto/NVIDIA (alternatively just enable the NVIDIA driver specific repository pre-provided by Fedora: dnf config-manager --enable rpmfusion-nonfree-nvidia-driver)
[1]: grubby --update-kernel=ALL --args="nvidia-drm.fbdev=0" && dracut -f
[2]: https://docs.fedoraproject.org/en-US/quick-docs/bugzilla-fil...
I truly believe that the Red Hat model is still possible to achieve today, but the barrier of entry is much higher than before. What sets Red Hat apart from many of these VC backed projects is what they actually offer. Red Hat doesn't primarily provide "services" or singular components like a database^, but delivers platforms.
RHEL, OpenShift, Ansible Automation Platform, OpenStack, Satellite, etc, are the aggregation of many open source projects tied together to make an offering appealing and attractive to enterprises. They produce the infrastructure and management layers of the stack that all your services and applications are deployed on. Working at this level enables a very different degree of flexibility and "safety" in comparison to single application or SaaS style offerings.
There's distinct boundaries of their products as well from the upstream variants: Fedora vs CentOS vs RHEL, OKD/SCOS vs OCP/RHCOS, RDO vs RHOSO, Ansible ecosystem vs AAP, etc. Red Hat also delivers on support, training/education, partner-driven sales, and OEM integration/certification.
^ Main exception would really be the Java middleware solutions, but the Runtimes and Integration offerings could be argued as a platform of their own. Same with RHEL/OpenShift AI.
Using a commit hash is the second most secure option. The first (in my eyes) is vendoring the actions you want to use in your user/org's namespace. Maintaining when/if to sync or backport upstream modifications can protect against these kinds of attacks.
However, this does depend on the repo being vetted ahead of time, before being vendored.
Sometimes side and off-the-cuff projects are just wacky enough to become amusingly interesting, and inspiring to try something crazy yourself.
For GUI notifications open the sealert app and disable alerts. For journal/syslog reports disable the setroubleshoot daemon dispatch plugin for auditd:
sed -i 's/active.=.yes/active = no/' /etc/audit/plugins.d/sedispatch.conf
service auditd restart
You can also uninstall the setroublshoot-server package completely, and all AVC denials will continue be reported separately outside of the journal.> being open source doesn’t automatically mean you can use the software commercially
I acknowledge there is a split in recognizing "open source" as between (a) a broad term of source code read-ability or (b) attributed to the specification defined by the Open Source Initiative. I see both arguments, but I believe using the OSI definition can eliminate some of these uncertainties.
* Despite the fact it's an end-user tool/application they will not be exposing, modifying, or extending in any way.
I may be misinterpreting here, so please do correct me.
Does the permissiveness of the license matter more than the utility of the tool? Whether or not an application/platform is using a permissive or copyleft license shouldn't really be a determining factor here for viability or vendor escape.
> But you can’t always find suitable FOSS etc.
This is the most prevalent problem, it's a lot easier to just spend money for a working tool than use an open source project that doesn't have everything you need, causes papercuts, and is being worked on in the developers' spare time.
However, a lot of FOSS options would be much better off if consumers did contribute to the project. Code is great, but financial support to the core developers goes much, much farther. Particularly if it enables them to prioritize the project over other things in life.
You may also want to try out <num><action> methods while in normal mode.
# Move forward 5 words
5w
# Move 20 lines up
20k
The latter paired with relative line numbering can be really handy.1. Translate the word to another language.
2. Get creative and make up an original name. Mixed translations, word-bashing, not-actual-words, there's a lot of options!
Okay, so the latter isn't super easy but can be a lot of fun to do!
In this case, it seems like a play on the core dependency name than choosing the actual word of "verso": servo -> verso.
For fun I asked Kagi "why haven't render times gotten better over the years?". The results were pretty spot on:
"""
Increased Complexity: As software evolves, the complexity of scenes and effects increases. Features like advanced lighting, volumetrics, and motion blur require more computational power, often offsetting any improvements in hardware.
Higher Quality Expectations: The demand for higher resolution and quality (e.g., 4K and beyond) leads to longer render times. Users expect more detailed visuals, which inherently take longer to produce.
Hardware Limitations: While hardware has improved, the efficiency gains may not be enough to keep up with the growing demands of modern rendering techniques. For example, ray tracing can dramatically increase render times, and not all hardware can handle it efficiently.
Software Optimization: Not all software updates prioritize optimization. Some updates may introduce new features that, while enhancing capabilities, also increase render times.
Rendering Techniques: Different rendering engines and techniques (e.g., CPU vs. GPU rendering) have varying performance characteristics. Depending on the setup, some may not see substantial improvements.
Overall, while there are advancements in technology, the balance between quality, complexity, and hardware capabilities often results in stagnant or even increased render times.
"""
That's not to say Red Hat is infallible. The internal organization of things does create misalignments around approach, path, and incentives. But it's not drastically different conceptually from any other business. There's just an inherit foundational hurdle of needing to convince potential customers that their products provide enough value over the upstream projects they derive from to agree to pay money for something they could, in essence, obtain at no-cost.^ Almost everything Red Hat does in the FOSS projects they contribute to can be a double edged sword.
^ No-cost can be a very, very loaded term. What you save on subscription costs may come back to bite you when trying to assemble or use something complex and rapidly developing. Your cost/risk tradeoff becomes staff with expertise, upstream communication, and operational reliability.
SIMD in Pure Python
https://www.da.vidbuchanan.co.uk/blog/python-swar.html
Don't let the "SIMD in Python" section fool you, it's a short stop on Numpy before putting it aside.
Before jumping straight into production k8s, something you can mess around with is using Podman to generate[0] and run[1] Kubernetes resources that you can parse through and familiarize yourself with. Paired with Podman Desktop[2] can produce a nice graphical environment. After that you could take a look at more production-simulating environments with minikube[3], OpenShift Local[4] (very much recommend if you have the resources to run it), and the no-cost OpenShift Sandbox[5].
In general, the Red Hat Developer[6] site has a lot of good resources to learn from, both passive and interactive. I highly recommend going through the courses and tutorials available if it can help your team skill up (assuming k8s is the direction you want to go in).
[0] https://docs.podman.io/en/latest/markdown/podman-generate.1....
[1] https://docs.podman.io/en/latest/markdown/podman-kube.1.html
[2] https://podman.io/features | https://podman-desktop.io/
[3] https://minikube.sigs.k8s.io/docs/
[4] https://developers.redhat.com/products/openshift-local/overv...
This is the way the world ends
This is the way the world ends
Not with a bang but a whimper.
---
Excerpt from The Hollow Men by T.S. Eliot[0].
I'll have to add it to the page, but it was also used as the introduction for The Compound by S.A. Bodeen[1]. It's an interesting young adult novel about a family living underground in a state of the art bomb shelter after a nuclear attack occurs.
[0] https://en.m.wikipedia.org/wiki/The_Hollow_Men
[1] https://bookshop.org/p/books/the-compound-s-a-bodeen/1554853...
If you rely on or have benefitted from this work, considering sharing some coin with them over on OpenCollective!
Sure, it has integrations with the broader Microsoft suite and productivity ecosystems making it easier to approve if the org is a M/O365 org. However, this is not a universal state (Google Workspace, Zoho Workplace, etc), and if the decision maker actually cares about communication efficiency then Teams would never be part of the discussion. There's such a wide field for messaging and calling applications, just going with "easiest bundle that ticks boxes" is rather poor thinking (not that I'm expecting much from C-Suites these days).
I currently have to use Teams today across macOS, Linux, and Windows... personally, I would welcome switching to Google Chat (used at last gig) over this mess.
That's kind of what it was designed for, though. GitLab.com wasn't a popular choice for open projects compared to GitHub until the "big migration" several years ago. Before that, GitLab was very popular for self-hosted internal instances (their customer reel demonstrated that). Even before modifying their OSS org policy for self-hosting, many groups ran their own GitLab CE instance. You couldn't (and still can't) do this with GitHub*. It also had a longstanding unlimited private repos compared to GitHub's free tier (formerly) that enticed developers.
GitLab's UI/UX was made for business workflows and processes (hence it being an "all-in-one DevOps platform." GitHub leans more into the community graph and semi-social media style for orgs/communities (the Discussions section a case example). It has come a long way for the business side, though.
* Yes, GitHub Enterprise Server exists: good luck getting it without paying for it (unless things have changed).