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

  • 🐕 I am attempting to get the site runnning as fast as possible. If you are experiencing slow page load times, please report it.
OSS now is a joke. it needs to be torn down and rebuilt. it's not savable, like a house infested with termites

CrunkLord420 said:
As referenced by a Linux-Rust maintainer who was stepping down: https://www.phoronix.com/news/Rust-Linux-Maintainer-Step-Down
Click to expand...
some of the comments are great

1724971315252.png
 
Last edited:
  • Winner
  • Like
  • Feels
Reactions: Playstation 2 Slim, troonshine, Spot 'em Slot 'em and 34 others
We believe that requiring a vote of the membership to remove a Code of Conduct violator from our community would subject members of the community — including people directly impacted by that violator’s behavior — to undue distress.
Click to expand...
How does casting a vote cause distress? Quite the contrary, someone who is genuinely a victim of bad behavior may relish the chance to vote to remove.

On the other hand, we believe there is significant legal risk that could arise from Code of Conduct violators known to the PSF using their status as a PSF Fellow to enhance their reputation.
Click to expand...
These people need better lawyers if they think this would pose a legal risk. That would be like if a criminal says they're a Harvard graduate to enhance their reputation, and so Harvard is sued.

You have to appreciate the dehumanizing language throughout of "Code of Conduct violator".

without further perpetuating the trauma caused by that community member’s actions.
Click to expand...
"Trauma." It's a programming language not a war.

This is entryism at its finest. Python is kill.
 
  • Like
  • Agree
Reactions: Mike Sneedsby, Last Ride, Lord Xenu and 22 others
I truly believe the future of kernels is with memory-safe languages. I am no visionary but if Linux doesn't internalize this, I'm afraid some other kernel will do to it what it did to Unix.
Click to expand...
is wedson an absolute fucking :lunacy:? (or, since he's brazilian, um corno viadão)
even if there were to magically be a troon squad full of autists ready to make their cute new kernel entirely in rust, it'd be nothing more than a dumb little toy that gets updated in progressively longer lengths until getting Our Incredible Journey'd. troons cannot create, they can only horribly distort what already exists. last time someone made a new notable kernel, the apple frankenstein controls flipped back in action the moment he worked on a browser again and now he's just kinda depressing to check in on my xitter feed.
 
  • Like
  • Agree
  • Disagree
Reactions: RepeatedMeme, Kola, Rusty Metal Skull Gun and 4 others
and like clockwork:
Debian Orphans Bcachefs-Tools: "Impossible To Maintain In Debian Stable" (archive.md)
Even before the Bcachefs file-system driver was accepted into the mainline kernel, Debian for the past five years has offered a "bcachefs-tools" package to provide the user-space programs to this copy-on-write file-system. It was simple at first when it was simple C code but since the Bcachefs tools transitioned to Rust, it's become an unmaintainable mess for stable-minded distribution vendors. As such the bcachefs-tools package has now been orphaned by Debian.
Click to expand...
 
  • Informative
  • Like
Reactions: Pee Cola, Chen Stirner, Another Char Clone and 13 others
jakkufurosuto said:
it's become an unmaintainable mess for stable-minded distribution vendors
Click to expand...
Unmaintainable because they have arbitrary rules they have made up where they have to do a bunch of extra work to swap out dependencies with versions the developer didn't intend to have their software used with. Building software with unsupported versions of dependencies is the opposite of what one would want in order to attain stable software.
 
  • Agree
  • Like
  • Informative
Reactions: Mike Sneedsby, Pee Cola, CEO of Gay and 8 others
Last edited:
  • Like
  • Dumb
  • Autistic
Reactions: NortelNutworks, Pee Cola, SFINAE and 6 others
UNIXLover said:
Unmaintainable because they have arbitrary rules they have made up where they have to do a bunch of extra work to swap out dependencies with versions the developer didn't intend to have their software used with. Building software with unsupported versions of dependencies is the opposite of what one would want in order to attain stable software.
Click to expand...
Unmaintainable because reasonable people don't make their software depend on an exact version of a library, and reasonable library-writers make their shit backward-compatible. This for some reason is accepted in the worlds of Rust and Python, but doesn't work well with the C and C++ ecosystems that distro maintainers are used to.

I swear Rust is secretly a Chinese plot to destabilize the West by making us waste our time dealing with constant bullshit.
 
  • Like
  • Thunk-Provoking
  • Agree
Reactions: NortelNutworks, Pee Cola, Kiwi2Shoes and 14 others
Rusty Metal Skull Gun said:
Unmaintainable because reasonable people don't make their software depend on an exact version of a library, and reasonable library-writers make their shit backward-compatible. This for some reason is accepted in the worlds of Rust and Python, but doesn't work well with the C and C++ ecosystems that distro maintainers are used to.

I swear Rust is secretly a Chinese plot to destabilize the West by making us waste our time dealing with constant bullshit.
Click to expand...
I haven't read the rust/kernel drama yet, but rust packages usually don't depend on specific versions. They depend on semver ranges 99/100 times. Whats likely happening is those version requirements are not multiple years old for debian. I'm not sure why they'd even care though, because rust is horrible at dynamic linking which is the main benefit to sharing a version.

Edit: another common requirement in rust projects is a recent compiler version, which debian probably doesn't like either. That usually comes in at the final package and not the libraries though, which often have minimum compiler versions from years prior.

Edit 2: also nightly compiler requirements suck, could be that. going to actually read it now.

So errno, which needed the exact version 0.2, was relaxed so that it could build with version 0.4 in Debian, udev 0.7 was relaxed for 0.8 in Debian, memoffset from 0.8.5 to 0.6.5, paste from 1.0.11 to 1.08 and bindgen from 0.69.9 to 0.66.
Click to expand...
The errno version is weird, but none of the others are semver compatible, which will break the build yes. As mentioned above I'm not sure why debian forces versions though, as you can barely dynamically link rust, and it is possible for a single rust package to have multiple versions of a dependency.
I found this a bit disturbing, but it seems that some Rust people have lots of confidence that if something builds, it will run fine. And at least it did build, and the resulting binaries did work, although I’m personally still not very comfortable or confident about this approach (perhaps that might change as I learn more about Rust).
Click to expand...
The guidance is concerning due to the semver major version bumps at least. It has a good chance of just working if it compiles though.
With that in mind, at this point you may wonder how any distribution could sanely package this.
Click to expand...
Don't force a single version of each rust package across your entire distro. It's simply not going to work.
 
Last edited:
  • Like
  • Agree
Reactions: RGBCube, Kees H, UNIXLover and 2 others
Rusty Metal Skull Gun said:
Unmaintainable because reasonable people don't make their software depend on an exact version of a library, and reasonable library-writers make their shit backward-compatible.
Click to expand...
I'd argue we're more or less seeing the breakdown of what an army of people can manage using shitty tools.
Looking Glass said:
Don't force a single version of each rust package across your entire distro. It's simply not going to work.
Click to expand...
No, everything should use the same version, the only version, because software should be finished and then left alone. If people could just define an interface, and get it right, then that would fix all of these problems.
 
  • Dumb
  • Like
  • Autistic
Reactions: HRT Heisenberg, SFINAE, Fascist Kirk and 5 others
UERISIMILITUDO said:
No, everything should use the same version, the only version, because software should be finished and then left alone. If people could just define an interface, and get it right, then that would fix all of these problems.
Click to expand...
That almost never happens, no matter what language or tools you work with. It's better to have a way to handle inevitable changes than expect things to just work.

Edit: In my own work I often don't try to get it perfect anymore. That usually just leads to decision paralysis and getting nothing done at all, or rewriting the same interfaces repeatedly to be more generic.
 
  • Agree
  • Like
  • DRINK!
Reactions: HRT Heisenberg, CEO of Gay, RGBCube and 4 others
Let's look at the dependency list for bcachefs-tools (https://github.com/gentoo/gentoo/blob/master/sys-fs/bcachefs-tools/bcachefs-tools-1.11.0.ebuild):

CRATES="
aho-corasick@1.1.2
anstream@0.6.11
anstyle-parse@0.2.3
anstyle-query@1.0.2
anstyle-wincon@3.0.2
anstyle@1.0.6
anyhow@1.0.79
autocfg@1.1.0
bindgen@0.69.4
bitfield@0.14.0
bitflags@1.3.2
bitflags@2.4.2
byteorder@1.5.0
cc@1.0.83
cexpr@0.6.0
cfg-if@1.0.0
clang-sys@1.7.0
clap@4.4.18
clap_builder@4.4.18
clap_complete@4.4.10
clap_derive@4.4.7
clap_lex@0.6.0
colorchoice@1.0.0
either@1.9.0
env_logger@0.10.2
errno-dragonfly@0.1.2
errno@0.2.8
errno@0.3.8
glob@0.3.1
heck@0.4.1
home@0.5.9
itertools@0.12.1
lazy_static@1.4.0
lazycell@1.3.0
libc@0.2.153
libloading@0.8.1
libudev-sys@0.1.4
linux-raw-sys@0.4.13
log@0.4.22
memchr@2.7.1
memoffset@0.8.0
minimal-lexical@0.2.1
nom@7.1.3
once_cell@1.19.0
owo-colors@4.0.0
paste@1.0.14
pkg-config@0.3.29
prettyplease@0.2.16
proc-macro2@1.0.78
quote@1.0.35
regex-automata@0.4.5
regex-syntax@0.8.2
regex@1.10.3
rustc-hash@1.1.0
rustix@0.38.34
rustversion@1.0.17
shlex@1.3.0
strsim@0.10.0
strum@0.26.2
strum_macros@0.26.2
syn@2.0.48
terminal_size@0.3.0
udev@0.7.0
unicode-ident@1.0.12
utf8parse@0.2.1
uuid@1.7.0
which@4.4.2
winapi-i686-pc-windows-gnu@0.4.0
winapi-x86_64-pc-windows-gnu@0.4.0
winapi@0.3.9
windows-sys@0.48.0
windows-sys@0.52.0
windows-targets@0.48.5
windows-targets@0.52.0
windows_aarch64_gnullvm@0.48.5
windows_aarch64_gnullvm@0.52.0
windows_aarch64_msvc@0.48.5
windows_aarch64_msvc@0.52.0
windows_i686_gnu@0.48.5
windows_i686_gnu@0.52.0
windows_i686_msvc@0.48.5
windows_i686_msvc@0.52.0
windows_x86_64_gnu@0.48.5
windows_x86_64_gnu@0.52.0
windows_x86_64_gnullvm@0.48.5
windows_x86_64_gnullvm@0.52.0
windows_x86_64_msvc@0.48.5
windows_x86_64_msvc@0.52.0
zeroize@1.8.1
zeroize_derive@1.4.2
"
Click to expand...
Of course it's normal that a Linux-only package would need two versions of windows_aarch64_msvc, why wouldn't it be?
 
  • Horrifying
  • Like
  • Informative
Reactions: NortelNutworks, HRT Heisenberg, botrix_fan and 17 others
Rusty Metal Skull Gun said:
Unmaintainable because reasonable people don't make their software depend on an exact version of a library, and reasonable library-writers make their shit backward-compatible. This for some reason is accepted in the worlds of Rust and Python, but doesn't work well with the C and C++ ecosystems that distro maintainers are used to.
Click to expand...
The language itself is insanely unstable. The bootstrapping path for rustc is complete fucking insanity, where iirc you start with a compiler in Ocaml for an ancient version and then go up one minor version at a time because the language changes so rapidly that the compiler two minor versions ago can regularly no longer compile the current compiler. Keep in mind that building rustc takes an hour or so, too. Together with the sprawl of microdependencies, you'd struggle to come up with a more fertile ground for supply chain attacks.

I think rot of this type at the language/reference implementation level has serious cultural consequences. You see a similar thing in the Python world (which had the infamous v2/v3 disaster) and the exact opposite in the Common Lisp world (where the language is stable almost to a fault and so are many libraries).
 
  • Like
  • Horrifying
  • Agree
Reactions: Mike Sneedsby, Wood, Wright and 19 others
306h4Ge5eJUJ said:
The language itself is insanely unstable. The bootstrapping path for rustc is complete fucking insanity, where iirc you start with a compiler in Ocaml for an ancient version and then go up one minor version at a time because the language changes so rapidly that the compiler two minor versions ago can regularly no longer compile the current compiler. Keep in mind that building rustc takes an hour or so, too. Together with the sprawl of microdependencies, you'd struggle to come up with a more fertile ground for supply chain attacks.

I think rot of this type at the language/reference implementation level has serious cultural consequences. You see a similar thing in the Python world (which had the infamous v2/v3 disaster) and the exact opposite in the Common Lisp world (where the language is stable almost to a fault and so are many libraries).
Click to expand...
Plus they still don't have a spec. And a community that's so political and cult-like that it's incapable of making rational decisions. The idea of letting something like that anywhere something as important and conservative as the kernel is lunacy.

I looked at the maintainers of bcachefs-tools to find the troon, and lo and behold we have "Kayla Firestack". Lol, imagine being a grown man and calling yourself that.

It looks like he works at the MBTA, where there's four troons on the team out of eight. No wonder Charlie couldn't get off that train.
Screenshot_20240830_142115.png
 
  • Horrifying
  • Informative
Reactions: Pee Cola, Lord Xenu, Chen Stirner and 11 others
You must log in or register to reply here.
Back