Carl George :fedora: :centos:

#RPM packaging nerd. Works on #EPEL, #Fedora, and #CentOS.

:github: GitHub: https://github.com/carlwgeorge
:wordpress: Gravatar: https://gravatar.com/carlwgeorge
:fedora: FAS: https://accounts.fedoraproject.org/user/carlwgeorge/
🦋 Bluesky: https://bsky.app/profile/carlwgeorge.bsky.social

Public Key

npub1q0t02a0s7vy0yf3tza48sl97592t85wzcrjlt8wszzl7up2c526sgvn0hx

NIP-05 Address

carlwgeorge_at_fosstodon.org@momostr.pink

Profile Code

nprofile1qqsq84h4whc0xz8jyc43w6nc0jl2z49n68pvpe04nhgpp0lwq4v29dgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dslcmzdp

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1q0t02a0s7vy0yf3tza48sl97592t85wzcrjlt8wszzl7up2c526sgvn0hx

Show more details

Published at

2026-08-10T12:59:59Z

Kind type

0 Metadata

Event JSON

{ "id": "2b88b04bc2eb6b0df48afcb5ce5a9e093496f2817896ebc1422309fb58ceca5f", "pubkey": "03d6f575f0f308f2262b176a787cbea154b3d1c2c0e5f59dd010bfee0558a2b5", "created_at": 1786366799, "kind": 0, "tags": [ [ "emoji", "fedora", "https://cdn.fosstodon.org/custom_emojis/images/000/225/367/original/f0c78925a380caa3.png" ], [ "emoji", "centos", "https://cdn.fosstodon.org/custom_emojis/images/000/776/782/original/5826a16bfb1ac471.png" ], [ "emoji", "github", "https://cdn.fosstodon.org/custom_emojis/images/000/025/112/original/b3e59f30ffe903a8.png" ], [ "emoji", "wordpress", "https://cdn.fosstodon.org/custom_emojis/images/000/783/434/original/8f12a175f938a062.png" ], [ "t", "fedora" ], [ "t", "centos" ], [ "t", "rpm" ], [ "t", "epel" ], [ "proxy", "https://fosstodon.org/users/carlwgeorge", "activitypub" ], [ "L", "pink.momostr" ], [ "l", "pink.momostr.activitypub:https://fosstodon.org/users/carlwgeorge", "pink.momostr" ], [ "-" ] ], "content": "{\"name\":\"Carl George :fedora: :centos:\",\"about\":\"#RPM packaging nerd. Works on #EPEL, #Fedora, and #CentOS.\\n\\n:github: GitHub: https://github.com/carlwgeorge\\n:wordpress: Gravatar: https://gravatar.com/carlwgeorge\\n:fedora: FAS: https://accounts.fedoraproject.org/user/carlwgeorge/\\n🦋 Bluesky: https://bsky.app/profile/carlwgeorge.bsky.social\\n\",\"website\":\"https://fosstodon.org/@carlwgeorge\",\"picture\":\"https://cdn.fosstodon.org/accounts/avatars/109/208/543/682/444/494/original/2ae3f673ee29a20e.jpg\",\"banner\":\"https://cdn.fosstodon.org/accounts/headers/109/208/543/682/444/494/original/e954c5140c94cdca.jpg\",\"nip05\":\"carlwgeorge_at_fosstodon.org@momostr.pink\"}", "sig": "2f9f3ac5daf103213bc77253f5889b6bca51787c14f1d3348c85a532a68e546614413d74a22eac3d06bfffe97b6ea44568d340899a655f373aa9a9b1bf1b618e" }

Last Notes

2026-04-22 18:25:45 UTC

- reply

Having a major version (and using the term "major-version stable") is how distro developers (like myself and Gordon) communicate the types of updates you can expect to see in a release, which translates to the stability for end users, as well as for third parties that build on the platform. CentOS Stream 10 has the same versions of glibc, openssl, curl, and other libraries as RHEL 10, because it functions as the RHEL 10 major version branch.

2026-04-22 18:19:09 UTC

- reply

So in your mind, the RHEL codebase (i.e. CentOS) goes from being unstable, to stable, then back to stable, then back to unstable, over and over again with every RHEL minor version that forks from the CentOS Stream major version? I'm sorry, that's just now how things work in the real world. The stabilization phase starts when a new major version forks from Fedora, and is concluded once the corresponding RHEL major version is released.

2026-02-17 18:34:03 UTC

- reply

Early primary voting starts today!

2026-02-17 17:38:43 UTC

Talarico is the real fucking deal.
"The culture wars are a smoke screen, because the real fight in this country is not left vs right, it's top vs bottom."
https://youtu.be/oiTJ7Pz_59A
#Texas
#USPol
#Vote

2025-11-20 08:36:24 UTC

- reply

I found your RFC for that in RPM, but I can't find anything indicating it was ever implemented. Am I missing something?
https://github.com/rpm-software-management/rpm/issues/3032

2025-11-06 21:54:16 UTC

- reply

Semi-related to some of these, but a bad pattern I notice often is paraphrasing others. Paraphrasing when done carefully can be a useful tool for clarifying intent and confirming understanding, but much more often it's used uncharitably to be dismissive of others' viewpoints. No one likes for their viewpoint to be boiled down to an inaccurate and demeaning false quote.

2025-11-01 23:01:36 UTC

- reply

Hmm, being limited to PCIe3.0x1 is a bummer. I may wait to see how their upcoming ME Pro and ME Max stack up on that front before making a purchase. I would happily pay more for a similar form factor with PCIe4.0x4.
https://www.bee-link.com/blogs/all/beelink-launches-new-me-series-storage-devices-first-product

2025-11-01 20:18:06 UTC

- reply

Oh that looks awesome! Thanks for sharing the details.

2025-11-01 20:00:33 UTC

- reply

What is that block of NVME slots from? A standalone product or part of a particular case? Seems nifty, and I've been contemplating an all-SSD NAS.

2025-08-28 01:02:51 UTC

- reply

https://open.spotify.com/track/2XtwwtBp9u14K1tIHAwiHQ

2025-08-27 21:43:22 UTC

- reply

Two additional notes on that loader trick.
- You don't have to remember the full loader path, you can just run ld.so (a symlink to the same, but in /usr/bin so it's in the PATH).
- It works for me all the way back to RHEL 8's glibc 2.28. I'm not sure if it was available in that version from upstream or if RHEL 8 backported it. Either way, pretty useful that it works in all current versions of RHEL.

2025-08-26 16:59:51 UTC

- reply

https://issues.redhat.com/browse/CS-2983

2025-08-01 21:36:04 UTC

- reply

If you don't know the dconf key name for something, you can run `dconf watch /` in a terminal and then change the setting in the GUI. The key name and value will print out in the terminal. Alternately you can use dconf-editor to browse the keys in an app.

2025-08-01 21:35:13 UTC

- reply

I highly recommend using ansible for this. Instead of a list of tweaks you have to apply manually, you keep that list in the form of a playbook you can just run against new systems. Most GNOME things (including extensions) store their configuration in dconf, and ansible has a dconf module to make setting those properties easy.
https://docs.ansible.com/ansible/latest/collections/community/general/dconf_module.html

2025-06-25 02:29:12 UTC

- reply

A bit of inside baseball, the Fedora Discourse let's you choose a "title" from a drop down menu that includes the groups in you're in but also the badges you've earned. Previously I had it set to "Proven Packager", but I thought it would be funny to set it to the title of this badge:
https://badges.fedoraproject.org/badge/corporate-shill

2025-06-25 02:26:02 UTC

- reply

I did that as a bit of an inside joke for [@mattdm](https://hachyderm.io/@mattdm ), as a throwback to a comment on LWN a few years ago.
https://cdn.fosstodon.org/media_attachments/files/114/741/616/736/979/971/original/d6c742133d29be50.jpg

2025-06-02 15:25:49 UTC

- reply

I'm glad you found them useful. You are correct that 10 works the same way. Here's an updated diagram.
https://carlwgeorge.fedorapeople.org/diagrams/el10.png

2025-05-21 14:44:48 UTC

- reply

All three are great choices. If you don't have a specific need for minor versions (like an application that is pinned to one) then I think CentOS Stream may be the best fit, as it will give you fixes and features sooner.

2025-05-20 15:51:31 UTC

EPEL 10 launched a little over five months ago. Today, RHEL 10 was released. In that time EPEL 10 has grown to 17,756 packages (from 5,451 source packages) built by 249 different Fedora packagers. 📦🎉🤩
https://fosstodon.org/@carlwgeorge/113642432557457454

2025-02-22 18:02:28 UTC

- reply

It obviously would make sense to do that, otherwise this problem keeps happening. If they want to test artifacts that haven't been pushed to the mirrors yet, do it in another image tag. There is zero reason for the main tag that is consumed by users to get pre-release content included like this.

2025-02-22 17:43:17 UTC

- reply

Composes happen daily, but are usually only pushed to the mirrors once a week on Mondays. The bootc image is built with the latest compose repos enabled, so if it builds on a Tuesday it could have packages baked in that won't be on the mirrors for nearly a week. They need to stop enabling the latest compose repos during the build, I'm not sure why they haven't yet.

2025-02-22 07:58:31 UTC

- reply

Sounds like this issue.
https://gitlab.com/redhat/centos-stream/containers/bootc/-/issues/1174
Basically the image gets a newer release of a package baked in than what is available on the mirror network, and then you can't install another subpackage from the same build that has a strict dependency on a matching release. Try downgrading to util-linux-2.37.4-20.el9 first, then installing util-linux-user.

2024-12-19 04:07:21 UTC

- reply

Blame Intel. Back when the levels were defined no one expected them to keep releasing CPUs that didn't qualify for the highest level. They were intended more for defining past generations of CPUs, not for splitting budget/premium product lines.

2024-12-19 04:00:56 UTC

- reply

No need for a separate tool, you can just run
ld.so --help
and it will show you what levels your hardware supports.

2024-12-14 17:13:02 UTC

- reply

Not official news as the venue contract isn't final yet, but we're targeting October in Austin. Once we lock that up we'll announce it in the usual places like the @npub1hpa…7hzy account here. Hope to see you there!

2024-12-13 12:39:51 UTC

- reply

Yes. What you see in CS 10 now is what is planned for the RHEL 10.0 GA in Q2 next year.

2024-12-12 23:25:06 UTC

On behalf of the EPEL Steering Committee, I’m happy to announce the availability of EPEL 10.
https://communityblog.fedoraproject.org/epel-10-is-now-available/
#EPEL #CentOS #RHEL

2024-12-12 05:05:16 UTC

You owe it to yourself to watch this killer talk from [@adamhjk](https://hachyderm.io/@adamhjk ) about free software, open source, fair source, and business.
"You sell that shit for money!" 🤣
https://youtu.be/rmhYHzJpkuo
#KubeCon #FreeSoftware #OpenSource #FairSource

2024-11-19 03:33:01 UTC

- reply

RHEL 10 plans to maintain desktop apps as flatpaks instead of RPMs. That's reflected in CentOS 10 already, as you observed. But anything that isn't present in the base operating system as an RPM is eligible to be added to EPEL as an RPM, including Firefox and Thunderbird. All it needs is a willing maintainer.
https://docs.fedoraproject.org/en-US/epel/epel-package-request/
#epel #centos #rhel

2024-10-26 19:45:10 UTC

- reply

Besides Wikipedia that you already mentioned, my most commonly used ones are:
fp https://packages.fedoraproject.org/search?query=%s
fs https://fedorapeople.org/groups/schedule/f-%s/f-%s-key-tasks.html
gh https://github.com/search?q=%s&ref=opensearch
cve https://nvd.nist.gov/vuln/detail/%s
man https://www.mankier.com/?q=%s
pypi https://pypi.org/search/?q=%s

2024-10-25 21:14:13 UTC

- reply

Was just about to reply about this feature. Tags make more sense to me for the approach described in that article, and you can access them with +tagname (and bookmarks can have multiple tags). But keywords combined with the %s in the URL feel like a legit super power.
BTW, I'm stealing your Python stdlib URL keyword, that's a great one!

2024-10-10 01:36:15 UTC

- reply

Good job @npub1kxe…m3e3!

2024-10-04 20:44:14 UTC

- reply

That part pissed me off. To kill an animal and just throw it in the brush is wasteful. Actual hunters get taught that when they're kids.
One time I was on a hunting trip and another hunter made the comment "let's go killing". The land owner didn't invite him back again. Killing to harvest wild game is normal. Killing for the sake of killing is weird.

2024-09-28 04:21:45 UTC

- reply

I keep seeing other people claim that Red Hat and Canonical rated these CVEs as 9.9, but nothing from either org where they actually did. Am I missing something? From what I can find, Red Hat rated them all important (not critical), with scores ranging from 6.1 to 8.2. Canonical rated them all medium.

2024-09-23 23:25:10 UTC

- reply

I figured it was only a matter of time until you came along to make spiteful comments. Being able to use a thing is not the same thing as the thing being a healthy and sustainable open source project. That's all I have to say to you on this subject, so don't waste your time replying further.

2024-09-23 23:17:22 UTC

- reply

Python is actually a great comparison. They have a similar situation with project vs output of the project, and an official name of an output (cpython) that is commonly referred to by shorthand (python). Originally they wanted people to keep the python command as 2, but more recent PEPs now say it's fine to have it be either 2 or 3.

2024-09-23 23:16:42 UTC

- reply

CentOS (Linux) 6 isn't CentOS (Linux) 7. CentOS (Linux) 7 isn't CentOS (Stream) 8. CentOS (Stream) 8 isn't CentOS (Stream) 9. Obviously different major versions are different. Doesn't make them not the same basic thing.

2024-09-23 22:56:56 UTC

- reply

Thanks for the assist on the explanation. Third party certifications are an important aspect that I didn't initially think to bring up, but they help illustrate the difference in release models.

2024-09-23 22:54:22 UTC

- reply

https://medium.com/@gordon.messmer/if-you-dont-understand-its-purpose-you-can-t-improve-the-process-4e48260c3887

2024-09-23 22:53:32 UTC

- reply

https://medium.com/@gordon.messmer/in-favor-of-centos-stream-e5a8a43bdcf8

2024-09-23 22:53:23 UTC

- reply

This isn't the easiest topic to summarize, so if you're curious to learn more I highly recommend @npub1ul4…wh3u's articles on the subject.

2024-09-23 22:52:31 UTC

- reply

Those baseurls help illustrate my point about most users ignoring the minor versions. Legacy CentOS technically had minor versions, but the default configuration only pointed you to the major version, which was a symlink to the latest minor for that major. Older minors were not maintained after the next one came out, so there was no overlap. Pinning to old minors was explicitly discouraged by the project.

2024-09-23 21:59:31 UTC

- reply

I'm a Fedora package sponsor and can help you get started. Can we switch to a GitHub issue in your project to discuss it further, or a matrix DM? I have the same username on GitHub and at matrix.org.

2024-09-23 20:40:27 UTC

- reply

The only reason we have the Stream suffix is because the project screwed up and tried to do both the legacy model and the new model in the same major version, instead of just making the switch at a major version boundary. This required a way to separately refer to the two variants. The Stream suffix no longer serves any purpose, because there is only one variant. I'm hopeful at some point we just drop it, like Fedora dropped the Core suffix years ago.

2024-09-23 20:34:55 UTC

- reply

Ok, you want to be pedantic? There is no distro named CentOS. The legacy distro from the CentOS project was named CentOS Linux. The widely accepted shorthand is to refer to the distro from the CentOS project as just CentOS. That used to be CentOS Linux, now it's CentOS Stream. It's not just me saying it, it's what happens in practice. Many people refer to it as CentOS 9, not CentOS Stream 9. I'm merely embracing that reality.

2024-09-23 08:09:50 UTC

- reply

Your "only question" is logical fallacy. Projects evolve. Would you argue that Python 3 isn't Python? Or openSUSE Leap isn't openSUSE? The CentOS project defines what CentOS is.
CentOS (Stream) defines what RHEL compatible means, so it's a great option. The exception is if you use vendor software with hard requirements on specific minor versions. But those usually don't keep up with the latest minor, meaning legacy CentOS didn't work either and RHEL EUS is the only valid choice.

2024-09-23 07:49:17 UTC

- reply

Because that's how RHEL works. Updates that fix bugs or security issues, if severe enough, are released to the current minor version. Everything else, including new features, are deferred to the next minor version. Historically, most CentOS users just applied available updates and ignored the minor versions. Dropping the minor versions means that now they get features, bug fixes, and security fixes sooner.

2024-09-23 07:32:50 UTC

- reply

And before you keep trying to explain to me what CentOS Linux and CentOS Stream are, understand that I used to build both. I know.
CentOS has always been two things: the project, and shorthand for the distro from the project. The project has more maintainers than ever before. The distro has a slightly different official name now, but many people still use the shorthand.

2024-09-23 07:26:17 UTC

- reply

1:1 rebuild is a fundamentally flawed model. By definition you can't fix bugs or accept contributions. See above meme. As a package maintainer, you should be able to understand that.
CentOS changed, accept it. It's no longer fundamentally flawed. It's now the major version that RHEL minor versions are created from. It stays major version compatible with RHEL, but has just enough room to change for the next RHEL minor versions. This is what CentOS is now, and it's a huge improvement.

2024-09-22 23:44:53 UTC

- reply

That period is just "released". There's no special name for it. CentOS releases updates after they pass QA. RHEL defers most of them to batch them up into minor versions. If you put them into a diagram, it would look like comparing a gradual slope versus stair steps. It's all the same major version and must follow the compatibility rules.
Why are you so insistent on calling it beta or testing? No one involved in the project calls it that. Why do you think you know better than us?

2024-09-22 22:52:17 UTC

- reply

It's not. It's a stable OS with major versions. Updates go through multiple levels of QA before being released. RHEL minor versions are derived from it. It's really not that complicated. Come on Joey, you can do it.

2024-09-22 22:37:55 UTC

- reply

Really, you're going to argue with me on this? Ok...
It's not a beta of RHEL. The beta of RHEL is...wait for it... actual RHEL Beta releases. Like RHEL 9 Beta in 2021, or RHEL 10 Beta coming soon.
And not similar enough? The only differences are the features and fixes planned for the next RHEL minor of the same major. C9 is basically RHEL 9.5 right now. Software version wise, it amounts to 5-10% difference. I've measured it over time.
Got any more misconceptions I can debunk for you?

2024-09-22 22:02:59 UTC

- reply

Congratulations, you've identified yourself as Joey in the meme.
CentOS Stream is CentOS.
Never fails that people online will "well actually" a literal subject matter expert.

2024-09-22 19:29:28 UTC

#centos #rhel #redhat
https://cdn.fosstodon.org/media_attachments/files/113/182/838/673/845/768/original/b5376d4c73a2a30d.jpg

2024-09-22 19:19:52 UTC

- reply

You just named my two favorite food groups 🍖🌮
Cajun and creole are close runners up. 🦐

2024-09-22 19:01:32 UTC

- reply

I've pretty much given up on "BBQ" outside of Texas because it's so consistently disappointing. Good ones do exist, but they're really hard to find.

2024-09-15 06:08:35 UTC

- reply

The best you can do is respect his wishes about having time to not stress about politics, and then revisit the topic later if you still need to vent about it. The state of politics here is stressful. My mentality is I'm going to be an educated voter, vote for people I think will at least try to improve things, but I refuse to think about it 24/7. I'm denying the assholes from living in my head rent free. Not saying you have to take the exact same approach, but it works for me.

2024-09-15 06:04:26 UTC

- reply

Me and my wife have had some similar interactions. She's empathetic to a fault, and sometimes will get into an anger/frustration/sadness spiral from political stuff. Sometimes I have to ask her to stop, or to take a break, for both our sakes. For example, we watched the last debate, but two days beforehand I told her I needed a moratorium on discussion of Trump until the debate, just to give myself a mental break. I could see a similar motivation for a politics-free night out.

2024-09-11 22:14:35 UTC

- reply

So from my limited exploration I was seeing massive dependency chains and an arguably trivial single function library. To me that looks like javascript. I'd love to be proven wrong on this.

2024-09-11 22:13:15 UTC

- reply

You definitely have a more holistic view of the the rust stack in Fedora than I do, but I will point out this wasn't a single look into it. Before I noticed is_executable, I had a few false starts trying to package rust programs. Each time I gave up after the transitive dependencies went over 100 (not even close to the final count either).

2024-09-11 21:50:49 UTC

- reply

That's good to hear it's improving, but is it going to be enough to stem the tide of the javascript-ification of the rust ecosystem? I worry that ship has sailed.

2024-09-11 02:17:32 UTC

- reply

Can someone invent a mic system that is like push-to-talk, but for a configurable time period? Like the moderator hits a button for a person to answer, and the mic is live for exactly X seconds. If they run over they're cut off, no moderator discretion other than hitting the button again for follow-up questions.

2024-09-11 02:07:02 UTC

- reply

good lord I needed that, thanks

2024-09-09 02:25:45 UTC

- reply

The surface area increase and tiny libraries are the things I'm arguing against, so it sounds like we agree on that part. My preference is for a rich standard library, comprehensive add-on libraries, and programs that carefully consider the impacts of adding new dependencies. I think the Python ecosystem excels in these areas, and wish Rust ecosystem would improve on them.

2024-09-09 02:19:40 UTC

- reply

Most of my points still apply inside containers. The mentality of "don't worry about what's in this container, just run it" is a problem, to your point about not claiming it's better.

2024-09-09 02:19:19 UTC

- reply

I think that without a way to measure that, it's hard to make judgements about either method becoming more or less popular. Anecdotal statements are too heavily influenced by the circles we run in. For example, my employer has tons of customers saying "we want you to provide more packages in your distro".

2024-09-09 02:02:28 UTC

- reply

Your second question feels like an argument about dynamic vs static linking, which is not the same discussion I'm having. My points are that distro packaging has value to many people, and in general having fewer dependencies (build-time or run-time) is better than having many. I would hope these aren't controversial statements.

2024-09-09 01:59:44 UTC

- reply

These are use cases that are served by distro packaging. There is absolutely nothing wrong with having both this method and the direct download single binary method. I would also argue that being present in disto default repos is a huge boon for discovery and adoption.
When software has an absurd number of build-time dependencies, it has no effect on the single binary download folks, but is actively harmful to the distro package folks.

2024-09-09 01:58:34 UTC

- reply

- They want to manage all software on their system the same way, e.g. install and upgrade with dnf/apt.
- They care about their software supply chain and how many entities they're trusting.
- They like their distro's update policies, e.g. holding back a new version with breaking changes until the next OS major version.
- They're working in an environment where they're only allowed to install software from their distro's repos.

2024-09-09 01:58:07 UTC

- reply

Obviously you don't care about build-time deps in your desired use case. But that is not the only use case that exists. There is a significant portion of users where the following statements apply:

2024-09-08 21:25:37 UTC

- reply

But why do those single binary things need to have hundreds of build-time deps? That's my point, not that statically compiled binaries themselves are bad.
The ideal case is that the deps are reasonable, so Linux distros can reasonably package the program, so users can choose between the distro-provided one (updated the same way as the rest of their system) or downloading a single binary from the upstream. Best of both worlds.

2024-09-08 21:15:42 UTC

- reply

I agree Redis isn't a full on analogy. My comment was intended to be limited in scope to this pattern:
- VC-funded company starts with open source to get momentum, perhaps even with good intentions
- VC applies pressure to get a return on their investment
- Company does a license change (usually enabled by a CLA) in pursuit of profits
I do think the risk of that pattern playing out applies, even if the details of consumption (SaaS or otherwise) aren't the same.

2024-09-08 20:06:35 UTC

- reply

There are real benefits to packaging deps over bundling, even with statically compiled languages, but the challenges from ridiculous amounts of dependencies are overshadowing the benefits. Rust and go are learning the wrong lesson from javascript.
https://fosstodon.org/@carlwgeorge/113093871162856348

2024-09-08 20:03:23 UTC

- reply

Yes for go, but no for the other two. When I look at packaging a C++ program, I usually see low single digit deps, and most/all of them are already packaged. Python isn't bad either, typically in the 5-15 range, but still with most/all of them already packaged. The last time I looked at packaging a rust program without bundling, I gave up after the transitive deps went over 100, and I wasn't even finished mapping them all.

2024-09-08 18:35:52 UTC

- reply

I can confirm that rust programs can be quite difficult to package in Fedora. I haven't really noticed a problem with compile times however, but rather the dependency sprawl (perhaps the complications you referred to). You either have to bundle everything (difficult to indicate all bundled software and licenses) or package each dependency separately.

2024-09-08 18:21:29 UTC

- reply

> but not as long as it’s MIT/Apache.
Haven't we seen this movie enough times (MongoDB, Elastic, Redis) to recognize the VC playbook on license changes?
I know you said in another reply that you expect Astral will flame out and the community will need to fork uv, but I think it's more likely they'll do a license change first. This would also result in a fork, but Astral then keeps uv going as proprietary software.

2024-09-07 23:34:04 UTC

- reply

Would be interesting to hear how well it works. Personally I prefer fresh installs, but I know there's substantial interest in the major version upgrade path.

2024-09-07 23:21:52 UTC

- reply

Won't someone think of those poor PCIe slots flexing under all that weight?

2024-09-07 20:21:38 UTC

- reply

Your second link has this image, which seems to indicate that CentOS Stream 8 to CentOS Stream 9 is possible with ELevate. Did you try it?
https://cdn.fosstodon.org/media_attachments/files/113/098/120/604/327/070/original/df09efc149d54c60.png

2024-09-07 07:49:04 UTC

- reply

Yeah I noticed your EPEL 10 build of it and thought to myself "surely there isn't a crate just for checking if a file is executable"...

2024-09-07 04:48:30 UTC

- reply

I take back the rude part, I see now that you edited pretty much right after you posted, I just didn't see it while I was typing out my reply. Sorry about jumping to conclusions.

2024-09-07 04:40:59 UTC

- reply

It's kinda rude for you to edit this from 160 to 100 after I corrected you. It makes me look like I was nitpicking a few lines rather than pointing out the reality was half of what you claimed.

2024-09-07 04:21:20 UTC

- reply

Excluding tests, comments, and whitespace, it's only 80. But we don't really need to bikeshed about "how many is too few" lines. Regardless of whether the implementation is trivial, the concept certainly is, and it's weird to me that the rust standard library doesn't already provide this functionality. The lack of a robust standard library leads to dependency sprawl, exploding supply chain sizes, more exposure for vulnerabilities, and more difficulty for distros to package apps/tools.

2024-09-07 02:18:44 UTC

Sadly it seems the javascript mindset of having add-on libraries for trivial functions instead of a robust standard library has infiltrated the rust ecosystem.
https://crates.io/crates/is_executable
#rust #javascript

2024-09-05 20:35:43 UTC

- reply

Easily found by doing a search for "android selinux" or "chromeos selinux".
https://source.android.com/docs/security/features/selinux
https://www.chromium.org/chromium-os/developer-library/reference/security/selinux/

2024-09-05 19:08:32 UTC

- reply

There is some nuance there. The fact that RHEL has a robust httpd SELinux policy makes it really easy for caddy in EPEL to reuse that policy to do webserver things. This is of course up to the volunteer EPEL maintainers to implement case by case, but at least it's a possibility.

2024-09-05 19:04:12 UTC

- reply

Exactly. No where in that article does it claim that is an all inclusive list, those are just six examples they chose to highlight. The article wouldn't be very readable if it was a wall of text with dozens of examples. There are routinely instances of the RH CVSS score being lower than the NVD CVSS score, often thanks to SELinux.

2024-09-02 22:15:14 UTC

- reply

Early on I had several former co-workers tell me they converted from CL8 to CS8 to check it out, then promptly forget that they did it. If you're just using it and not trying to examine the patch level of each package, you'll be hard pressed to find differences.

2024-09-01 20:14:24 UTC

- reply

Yup, that copr is the ideal method right now. The guy behind it started the Fedora COSMIC SIG, and we're using that copr for package reviews also, so it will continue to get closer and closer to the eventual official Fedora packages.
#fedora #cosmic

2024-09-01 16:55:14 UTC

- reply

For me, Fedora strikes the best balance of capability (features), up to date software (first), and community (friends). Those three aspects, along with the table-stakes dedication to open source (freedom), make up Fedora's core values.
https://docs.fedoraproject.org/en-US/project/#_what_is_fedora_all_about
#fedora

2024-09-01 16:40:34 UTC

Tired: "CentOS is dead."
Wired: "RHEL and all RHEL-like distros are CentOS derivatives."
#centos #rhel

2024-08-31 16:46:14 UTC

- reply

Great news, my wild idea has been merged.
PRETTY_NAME="CentOS Stream 10 (Coughlan)"
https://gitlab.com/redhat/centos-stream/rpms/centos-release/-/merge_requests/56

2024-08-24 23:48:16 UTC

- reply

Sure, I just felt it could use a bit of elaboration. Some people think that CentOS Stream is a completely separate project, or think it's a drastically different distro than classic CentOS Linux, neither of which are true. If the project hadn't tried to do both the old model and the new model in version 8, we wouldn't even have the Stream name. It's a messy history, but the future is bright.

2024-08-24 05:01:35 UTC

- reply

While it's technically true that CentOS is now between Fedora and RHEL, that is a bit misleading. CentOS branches off from Fedora, and then RHEL minor versions branch off from CentOS. CentOS is the RHEL major version. CentOS is only close to Fedora during the initial branching of a major version, and after that it is much closer to RHEL throughout its lifecycle.
https://cdn.fosstodon.org/media_attachments/files/113/015/235/581/530/175/original/98f94b116f289548.png

2024-08-24 05:00:08 UTC

- reply

CentOS is not dead, it's thriving. It's no longer just a RHEL clone, it's a distro in it's own right. This means the maintainers can finally fix bugs and accept contributions. Speaking of those maintainers, there are now several orders of magnitude more of them thanks to these changes. The tweak to the name just reflects that it is built differently now. It's common to see people still refer to it as CentOS, just like they did when the full name was CentOS Linux.

2024-08-05 02:27:45 UTC

- reply

No idea, but I can throw the idea out there.
Unrelated but kinda related, I've also got a wild idea about CentOS sharing code names with RHEL. So if we had been doing it for 9, it would have been:
VERSION="9 (Plow)"
PRETTY_NAME="CentOS Stream 9 (Plow)"
I think that would be a cool thing to do in 10 to reinforce the CentOS/RHEL relationship.

2024-08-05 01:38:48 UTC

- reply

This is exactly how it should be. The only piece we're missing is RHEL adding "centos".

2024-08-05 01:37:41 UTC

- reply

Symmetric relationships are explicitly mentioned in the specification, so this works.

2024-08-05 01:33:32 UTC

- reply

You trimmed out an important part.
> An OS should generally only list other OS identifiers it itself is a derivative of, and not any OSes that are derived from it, **though symmetric relationships are possible**.
(emphasis mine)
If CentOS and RHEL aren't a symmetric relationship in this context, I don't have a clue what would be.

2024-08-04 21:21:03 UTC

- reply

Nothing will be as bad as Oracle shipping an identical redhat-release file as actual RHEL so they can trick vendor software that does a string check on that file to enforce running it on RHEL.