Open Source Software Community - it's about ethics in Code of Conducts

You know firewalld has failed as a concept when you're entering direct netfilter rules into it anyway. And your first SELinux system, as either a sysdamin or a developer, is an endless gauntlet of things that used to work perfectly, just not doing so anymore. You will literally waste hours trying to fix configuration that should work and has worked, until you learn to always blame SELinux first and check whether it is stepping in.

True, but I'd say that I'm neither a "proper" sysadmin nor a developer; I'm just a home user traipsing about haphazardly. Having said that... I think the trade-off in SELinux and firewalld's irksome complexity and utterly baffling conceptual frameworks is more than worth enduring for fucking Cockpit. It's such a handy and useful thing for a headless server! I ain't even managing server racks or VPSes remotely. I'm operating out of an older gaming PC that I can still physically look at, get to power on and off, hook up to monitors, ethernet, and all this other stuff.

With Cockpit plus all the other virtualisation and containerisatoin stuff that naturally come with the Red Hat sphere of influence, I could honestly understand the appeal of wanting to run Fedora on an Intel N100 or a Ryzen APU mini PC. Sadly, it would appear that Ubuntu LTS, Proxmox, Debian Stable, and related projects are filling that niche of "baby's first home server." Technically, the same is true for me since my first home server project was Pi-Hole on a Raspberry Pi running Raspbian. But if you're already veering into mini PC or repurposed desktop territory, Fedora really ain't that bad of an option.

***

@Unimaginative Username - OpenBSD is great if you have older hardware. Last time I took a look at OpenBSD, they didn't support any AMD graphics cards beyond the Southern Island cards (i.e. HD 7970, R9 series, etc). My Vega requires AMDGPU, which FreeBSD's had for a long time but OpenBSD doesn't. Headless is headless, ssh is ssh, but I love the option of just plugging in cables and immediately having a graphical interface without needing to install one.
 
1766285943773.png
Cockpit does run on Ubuntu, though you do have to add a stupid stub file for netplan because it refuses to acknowledge that Ubuntu uses Network Manager and so the package manager refuses to work until you fix it with the stub file.

Honestly if I understood backports when i built my current server I would've used Debian but at the time Debian didn't support my Intel Arc gpu for transcoding. but Ubuntu works fine and all the scripts and software I use (that are not docker) work fine in it.
 
I wouldn't be surprised if (some) people attacking Framework are industry plants trying to get Framework to stop contributing at all.
Their priorities are always backwards. It should be:

Ousting pedophiles like Jeremy Bicha >> getting repairable laptops >>>>>>>>>> sperging about """Nazis"""

But instead it's:

Banning """Nazis""" >> getting repairable laptops >>>>>>>>>>>>> Ousting Jeremy Bicha

It doesn't make sense to me.
 
Their priorities are always backwards. It should be:

Ousting pedophiles like Jeremy Bicha >> getting repairable laptops >>>>>>>>>> sperging about """Nazis"""

But instead it's:

Banning """Nazis""" >> getting repairable laptops >>>>>>>>>>>>> Ousting Jeremy Bicha

It doesn't make sense to me.
I'm not confident that ousting Jeremy Bicha is even in their list
 
I wouldn't be surprised if (some) people attacking Framework are industry plants trying to get Framework to stop contributing at all.
You don't have to be a plant to engage in self-destructive behaviors.
An average specimen like this doesn't concern himself with whats going to happen in the next 5 years because he'll either be 6 feet under or 2 feet over the ground in that timeframe.
An average specimen like this is so grossly misdirected by corporations and actual industry plants they bash random joe schmoes on the internet for having the wrong beliefs while being raped for everything they have by firms and companies that actually make money off this retarded infighting.
 
But at large people do demand it, like all the wailing about that nginx ingress manager for kubernetes that is going away bc the standard had moved on, and the one guy maintaining it gave up.
¯\_(ツ)_/¯

If you ever find yourself the unappreciated, beleaguered, sole maintainer of something important, I recommend you brick it and announce a ransom fundraiser if they would like maintenance to resume. Sometimes people need to see what losing XYZ looks like before they take the complaints seriously. They can roll it back a version, sure, but now they know what the loss entails and the clock is ticking. No FOSS contributor should think their constant groaning will be met with sympathy or even attention. It is ambient noise.

No one gives a shit about the garbageman until he goes on strike.
 
¯\_(ツ)_/¯

If you ever find yourself the unappreciated, beleaguered, sole maintainer of something important, I recommend you brick it and announce a ransom fundraiser if they would like maintenance to resume. Sometimes people need to see what losing XYZ looks like before they take the complaints seriously. They can roll it back a version, sure, but now they know what the loss entails and the clock is ticking. No FOSS contributor should think their constant groaning will be met with sympathy or even attention. It is ambient noise.

No one gives a shit about the garbageman until he goes on strike.
Gotta go with a more aggressive version of what libxml2's maintainer did, and file any privately received CVEs and other disclosures as public issues. Wow, look, there's a publicly known vulnerability that could compromise your business! Sure would be nice if someone bothered to fix it, or pay someone who knows the project well...
 
No FOSS contributor should think their constant groaning will be met with sympathy or even attention. It is ambient noise.
You are at a crossroads. Do you sacrifice any credibility you had or could have dreamed of having on the altar of recognition or simply remain the quiet background character keeping half the world revolving, begging for a day someone will respect you for what you did?

As a maintainer for a critical library or piece of infrastructure you hold incredible leverage. The leverage exists until the very moment you start using it. Once you reveal where you stand and that you're essentially scuttling your work you burn everything around you not just for the corporations piggybacking off you like leeches, but the average macaque having to deal with this new fascinating development of yours. There's no one-size-fits-all outcome for doing stuff like this, for example if the guy behind is-odd decides to chimp out he'll be easily replaced, ffmpeg going on strike on the other hand could grind everything to a complete halt, with outcomes ranging from proprietary ffmpeg analogues or actual funding depending on what would be the least of a liability.

Realistically speaking by going the marak route all you're going to get is attention without any substantial change to your situation or to that of the project you're maintaining.
 
Last edited:
View attachment 8312569
Cockpit does run on Ubuntu, though you do have to add a stupid stub file for netplan because it refuses to acknowledge that Ubuntu uses Network Manager and so the package manager refuses to work until you fix it with the stub file.

Honestly if I understood backports when i built my current server I would've used Debian but at the time Debian didn't support my Intel Arc gpu for transcoding. but Ubuntu works fine and all the scripts and software I use (that are not docker) work fine in it.

Fair enough; tons of Fedora/RHEL stuff is basically 1:1 interoperable on any systemd-first distro if you bother to set it up. There are also other odds and ends that make something like Debian/Ubuntu and their clones less painful to use than Fedora/RHEL. Even so... it just blows my mind that "Fedora's a testbed for RHEL" is a soundbyte that's thoroughly entrenched in the broader community... yet no one seemingly cares enough to actually try the testbed stuff.
 
Do you sacrifice any credibility you had or could have dreamed of having on the altar of recognition or simply remain the quiet background character keeping half the world revolving, begging for a day someone will respect you for what you did?
Screenshot_2025-12-20_23-52-53.png


>the people who do it for free have a self-worth problem

All I can really suggest is that such people cast a steely eye on what their project actually needs to remain sustainable - including feeding the coder his tendies - and have the guts to ask for it; because that's the narrow path between skeezy greedy for-profit walled gardens and self-cannibalizing anarcho-communism. Programmers are artisans at the end of the day, and artisans are obligated to their craft.
The best philosophy is the one that best serves the craft.
 
As a maintainer for a critical library or piece of infrastructure you hold incredible leverage.
There are three different types of free/open source maintainers:

1, The original breed of public domain, and what later migrated towards open or free source. Someone that does it because they enjoy it. Often it originated because it would solve a problem the maintainer had and it evolved into a public project/tool/library/application/...
These do it because they enjoy it. They do not use social media much but if they have others that contribute contribute and talk over email and similar.
Maybe occasional status report on social media but they do it for the fun of it, and when they have users depend on it, for the responsibility towards the users. They don't do it for the twitter updots.
You can depend on these people. You might not be able to talk to them at the drop of a hat or form a para-social relation with them but they will try to maintain and fix issues you have.
You communicate with these mostly via email-lists and issue trackers. If you are a peer-developer you might interact with them directly via private email-chain.

You can mostly depend on these people.
For conflict management, if you annoy them enough they will block your email, ignore you and maybe ban you from the issue tracker.

2, Later came the paid maintainers. People that support and maintain a package because it is their paid job.
This is more recent but are people employed at tech companies and/or distros and who literally do this as their paid job. They might not be as passionate about the project as it sometimes is "just a job" but many of them are passionate.
You can absolutely depend on these people too. Maybe you can depend on them even more than 1, since there is there is someone behind the scenes willing to pay someone to do this. So bus-factor is higher than in 1. You WILL have a new maintainer if for any reason the current one can not continue maintaining it.
Main difference in support compared to 1, is that 1, will prioritize your issue if it interests the maintainer while in this case it is more crud will prioritize based on who pays for it.
These people also do not spend super-much time on social media. They are payd to maintain the codebase, not have discussion club on twitter.
You communicate with them on a dedicated email-list or in the issue tracker or via the account manager if you are an important paying customer.

You can mostly depend on these people.
For conflict management, if you annoy them enough they will block your email, ignore you and possibly also ban you from the issue tracker.

3, most recent "maintainers". Twitter-trannies. These people have neither interest or drive.
These are not really very experienced or skilled but they are very visible on social media.
These people are only motivated and driven by updots and validation on social media.
The project itself is of zero actual value to them beyond being a vehicle to get social media validation. When the project no longer provides social media validation the project is useless and is also dead.

They create projects at the drop of a hat with a massive storm of posts on social media to announce it and self-congratulate themselves.
They also drop/abandon projects just as quickly and with no warning because it no longer interests them, it was more difficult or required more work than they expected, they got bored or they were misgendered somewhere or some other imagined slight that caused them to rage quit.
This happens with no warning and sometimes they also sabotage the project, either by just deleting it or creating logic-bombs to, I guess, "strike back at the ungrateful nazi haters" that were using the project.

You can 100% NOT depend on these people. At any moment some imaginary slight might cause them to rage quit in a huge shit-show that will burn the project to the ground.
If this happens and they just destroy the project, you are lucky. Sometimes they destroy the project and ALSO destroy YOUR project. Sucks to be you if that happens.

These project almost always have a bus-factor of one. Since a turbo-narcissist seldom get along with or can share praise or validation with others. Instead they often drive other competent potential contributors away as they are a threat that may steal some of the praise or lime-light of maintaining the project.

For conflict management, if they feel slighted they will open the gates to hell and burn everything to the ground and then nuke the ashes. If they feel you had unreasonable demands, in actuality or if they made it up in their minds, they will go scorched earth on you and your company on social media, make things up, exaggerate shit and try to get other insane people on social media to go to your house and murder you and your family.


Never ever under any circumstances make yourself depend on a project in group 3.
2 is best because if you REALLY depend on it you REALLY need something done you can buy that support with the exchange of money. You can influence priorities in exchange of money.
1 is cheaper and also reliable but you always risk of encountering the maintainer that says "I will do it at some stage but it is low priority to me, I am also kinda rich so I don't care about what money you offer me. If the idea is boring then it is boring and it will get low prio in my to-do-list"
 
Last edited:
Nextcloud is a pozzed project
It's also a patched-together piece of symfony PHP piece of shit. It's docker container is a joke, runs rsync to copy it's files into a volume on each update, so if an upgrade very fails your SoL. Run opencloud. Runs on a real language, and doesn't even need a database
 
Debian but at the time Debian didn't support my Intel Arc gpu for transcoding.
Trixie supports it... kinda?
1766320549282.png
QSV/VAAPI seems to work fine as long as the application/container can write to /dev/dri /dev/renderD128 but their inferencing and compute parts are a fucking mess to say the least.

I got ollama and immich's inference engines to work, but immich will shit itself and burn if i use clip model other than ViT-L-16-SigLIP2-256__webli.
 
ffmpeg going on strike on the other hand could grind everything to a complete halt, with outcomes ranging from proprietary ffmpeg analogues or actual funding depending on what would be the least of a liability.
Not really. If coal miners go on strike, the coal mine grinds to a halt. If FFmpeg devs go on strike, the code stops improving but everything still works. Corporations wouldn't care at all. They'd be stuck with something imperfect, but if their customers don't know or care that the current AAC implementation in FFmpeg sucks, why would they?
 
Back
Top Bottom