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

  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
Forgot the fact that Apache did the gay ass approach of changing their logo for "ethos of community over code".
1764909346921.png
They still call themselves Apache because that would require a little too much actual work for these performative fags to change everything relating to it.
 
306h4Ge5eJUJ said:
You forgot the best 300 IQ decision: whether parameters are passed by value or by reference is almost entirely up to the compiler. Because missed optimization opportunities for copy elision are a Very Big Deal That Must Be Addressed By A Modern C Replacement, whereas half the code being subtly buggy and unportable between compilers is a minor detail and really you should just git gud.
Click to expand...
Is there any other language with sane compile time programming, good error handling and can include C headers directly (not needing to write a wrapper)? I'll gladly switch away from zig in that case.
 
dec05eba said:
Is there any other language with sane compile time programming, good error handling and can include C headers directly (not needing to write a wrapper)? I'll gladly switch away from zig in that case.
Click to expand...
Might be worth looking into cgo or Carbon. I know cgo takes forever to compile. I've never used Carbon, but C++ interopt is supposed to be a big tentpole feature for them.
 
dec05eba said:
Is there any other language with sane compile time programming, good error handling and can include C headers directly (not needing to write a wrapper)? I'll gladly switch away from zig in that case.
Click to expand...
I forgot that I have the answer to my own question: Jai. But it's still in closed beta.
 
Betonhaus said:
Is there a HolyC compiler for Linux?
Click to expand...
There is: https://holyc-lang.com/ i am currently playing with it so might report later on how shit/good it is.

EDIT:
It doesn't handle I32 properly.
The parsing of Clibs argument isn't implemented however it is trivial to implement it.
Global Variables aren't supported.

However it is possible to desecrate HolyC by linking it with atheist code such as ray lib.
 
Last edited:
Ariadne Conill said:
For example, after rejecting Xlibre in Alpine due to their reactionary background, a notable alt-right Linux podcaster made a video targeting me, focusing on my transgender identity rather than the technical merits.
Click to expand...
>bitching about Lunduke
:story:
Also what technical merits? There is literally no technical merit to rejecting Xlibre.
 
WielkiWapiesz2137 said:
HolyC is closer to C replacement than Zig will ever be.
Click to expand...
Something I somehow didn't know, or didn't really pat attention to until recently, is that holy C is able to be JIT compiled. Unless where I saw that was mistaken.

Which I thought was actually really interesting. I imagine using it like that could potential have a bit of a slow startup time, but the speed of the program after could make up for it, if you were to write something that only relies on that. To basically act like an interpreted language, but C.

I'm sure I did hear Terry mention that at some point, but it probably just few over my head at the time.
 
Oh boy, it's time for everyone's favorite topic!

LWN: Eventual Rust in CPython (paid link taken from lobsters) (archive)

Emma Smith and Kirill Podoprigora, two of Python's core developers, have opened adiscussion about including Rust code in CPython, the reference implementation of the Python programming language. Initially, Rust would only be used for optional extension modules, but they would like to see Rust become a required dependency over time. The initial plan was to make Rust required by 2028, but Smith and Podoprigora indefinitely postponed that goal in response to concerns raised in the discussion.
Click to expand...
In response to the concerns raised in the discussion, Smith and Podoprigora scaled back the goals of the proposal, saying that it should be limited to using Rust for optional extension modules (i.e. speeding up parts of the standard library) for the foreseeable future. They still want to see Rust adopted in CPython's core eventually, but a more gradual approach should help address problems raised by bootstrapping, language portability, and related concerns that people raised in the thread, Smith said.
Click to expand...
At the time of writing, the discussion is still ongoing. The Python community has not reached a firm conclusion about the adoption of Rust — but it has definitely ruled out a fast adoption. If Smith and Podoprigora's proposal moves forward, it still seems like it will be several years before Rust is adopted in CPython's core code, if it ever is. Still, the discussion also revealed a lot of enthusiasm for Rust — and that many people would rather contribute code written in Rust than attempt to wrestle with CPython's existing C code.
Click to expand...
 
Markass the Worst said:
>bitching about Lunduke
:story:
Also what technical merits? There is literally no technical merit to rejecting Xlibre.
Click to expand...
while there aren't any real technical merits, i can think of at least one valid political (as in "i feel like i know exactly what kind of developers these are and how their work developing software will go" as opposed to "this guy votes for different guys than i do") merit. it makes some sense to not allow xlibre over being a 2-day-old reactionary fork (they are just as likely to die incredibly quick as they are to live for a long time)
but we all know the real reason why this troon doesn't want xlibre

prollyanotherlurker said:
Something I somehow didn't know, or didn't really pat attention to until recently, is that holy C is able to be JIT compiled. Unless where I saw that was mistaken.
Click to expand...
regular c is able to be jit compiled as well. it's just not very popular, because c is very amenable to aot compilation and that's generally what everybody does
prollyanotherlurker said:
an interpreted language
Click to expand...
stop being one of those retards that thinks there is some sort of distinction between "interpreted languages" and "compiled languages"
 
Max Weber said:
Emma Smith and Kirill Podoprigora, two of Python's core developers
Click to expand...
Both are core developers for only a few months and just over a year respectively. Also one confirmed tranny.

This isn't a case of decades old veteran core developers making a decision based on technical merit, but of two kids in their honeymoon phase with Rust.

The reasoning for infecting project like Linux, Git and now Python with Rust has primarily been that "nobody wants to write C anymore, we need to attract more new developers/maintainers". It's the same reasoning as importing Indians and the like for cheap labor: "nobody wants to do job X, we need more immigrants doing those jobs". These kinds of people have no regard for quality and stability.
 
William Pitcock aka Ariadne Connill wrote:
For example, after rejecting Xlibre in Alpine due to their reactionary background, a notable alt-right Linux podcaster made a video targeting me, focusing on my transgender identity rather than the technical merits.
Click to expand...
Not to be a grammar Nazi, but the dangling participle made me chuckle.
 
WhiteNight said:
Not to be a grammar Nazi, but the dangling participle made me chuckle.
Click to expand...
I've an inkling somethin' else's gonna be dangling real soon if you know what I mean.

1764971779996.png



Creative Username said:
it makes some sense to not allow xlibre over being a 2-day-old reactionary fork (they are just as likely to die incredibly quick as they are to live for a long time)
Click to expand...
Makes me froth at the mouth how these disgusting fucking faggots blacklist XLibre but shill an actual reactionary cope like Wayback (thanks Will!). Just so happens I was reading a thread on the guix-devel mailing list about a proposed mainline XLibre package, and although most people keep a level head, there are a couple of gemmy replies even there (see spoiler). Guess it was a little too optimistic to expect there'd be no troons in a project as technical as Guix.
Re: xlibre X11 server
From: λx . x
Subject: Re: xlibre X11 server
Date: Wed, 02 Jul 2025 16:42:46 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

It is always a bad idea to give reactionaries a platform, and packaging
software that has "404" in their CoC file and write that they forked the
upstream project "because of woke", and "exclusionary practices such as
DEI and Codes of Conduct" in their README is doing just that. How about
we make like Chimera Linux and do not do that? I, as an X11 user (GNOME
and more recently StumpWM) will keep using X.Org or switch to Wayland
before i even take into consideration using software written and
maintained by nazis (and take into consideration i will not).

> July 2, 2025 at 8:00 AM, "Gabriel Santos" <gabrielsantosdesouza@disroot.org>
> wrote
>> Em 2 de julho de 2025 08:17:46 BRT, Ekaitz Zarraga <ekaitz@elenq.tech>
>> escreveu:
>>> We also package suckless software and there is plenty of information on the
>>> internet saying they are Nazis.

Sure, but this is still not a point in favor of packaging MORE software
from Nazis, is it? One could argue that suckless software has useful
qualities that some other software does not (i will not argue that, as
it is my opinion that it does not, but still), while i am yet to see ANY
useful qualities of xlibre over upstream X.Org apart from "cleansing" it
from "evil RedHat" and "DEI". In other words the project is total and
absolute bullshit.

>>> If Xlibre is libre and doesn't include malware, why shouldn't we
>>> package it? Adding it doesn't mean we support their opinion in any
>>> regard.

Again, the worst mistake you can make when dealing with reactionaries is
giving them platform, which packaging xlibre does. Do not feed the
trolls.

>>> So yeah, spacecadet, if you really want to continue to package it,
>>> we would add it to Guix,
>>> [...]
>>> If you really want it, don't be discouraged.
>> Agreed.

Reading this was downright disenchanting.


>>> [...] I don't think there's any policy in Guix
>>> against it [...]

Then, I believe, there should be.

jbranso@dismail.de writes:

> As a white man, it made me a little sad that I was not allowed to participate
> in outreachy. :(

I bet this hurt much more than what oppressed minorities have to put up
with their whole lives (this was sarcasm, mind you), not even sure what
the purpose of this line was.

+++

jbranso@dismail.de writes:

> I also think that Xlibre should be packaged.
>
> KiCad just blogged about how their software works better on X than wayland.
> https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support/
>
> X.org is not getting developed further, but Xlibre is trying to update the
> codebase.

There are alternative approaches to this issue which I think are more
viable.

https://github.com/kaniini/wayback for instance seeks to provide enough
of an X11 environment to run full X11 DEs atop Wayland.

This will require a much smaller codebase than to maintain the entirety
of a standalone X11 implementation and a consequently lesser maintenance burden.
 
You must log in or register to reply here.
Back
Top Bottom