overview for BB

Every dependency you add is a supply chain attack waiting to happen by BB_C in c/programming@programming.dev

[-] BB_C@programming.dev 1 points 1 day ago

I will let you expand on this before responding to both:

And also, cargo.toml has inconsistencies and double-standards.

Every dependency you add is a supply chain attack waiting to happen by BB_C in c/programming@programming.dev

[-] BB_C@programming.dev 2 points 2 days ago* (last edited 2 days ago)

Not cargo per se, but even the tutorial for a cli-tool is like “setup clap, which has 20 dependencies and a kitchen sink”. The whole (cargo-centric) ecosystem is much like Node, with the same problems.

cargo new with-clap
cd with-clap
cargo add clap --no-default-features

% cargo tree
with-clap v0.1.0 (/tmp/with-clap)
└── clap v4.6.0
    └── clap_builder v4.6.0
        ├── anstyle v1.0.14
        └── clap_lex v1.1.0

And also, cargo.toml has inconsistencies and double-standards.

Can you expand on that?

Every dependency you add is a supply chain attack waiting to happen by BB_C in c/programming@programming.dev

[-] BB_C@programming.dev 2 points 3 days ago

Why do you think cargo is a problem?

Is it bad form to patch a dependency? by BB_C in c/programming@programming.dev

[-] BB_C@programming.dev 1 points 5 days ago

Not sure how are you and @kibiz0r@midwest.social coming up with these concerns.

The only correct way to package such software is to vendor dependencies (packaged together or separately). And you can trivially change the sonames of vendored deps in your build scripts so that there are no conflicts whatsoever (I dual-package some stuff against an upstream and a fork and do just that). So dynamic vs. static is not the crux of the issue. The primary concerns are that distributors hate vendoring, irrespective of whether the vendored libs are linked in statically or dynamically. Distributors also hate potentially diverging forks maintained by random downstreams, which is what "patched dependencies" effectively are.

There is always room for some leeway of course, but that would depend on how relevant your software is, and/or whether a maintainer would want to take that burden on.

And finally, sometimes, such dependencies may provide added value that trumps all these concerns. So judging these things is always situational.

Is it bad form to patch a dependency? by BB_C in c/programming@programming.dev

[-] BB_C@programming.dev 1 points 5 days ago

Then you could be forced to vendor everything. And if it's open-source and relevant for distros to pickup, then you will need to find out if distros would be willing to take your library with its vendored libs (or package them separately just for your library)...etc.

And you may need to figure out if there are bus factor concerns with your direct dependency, since such libraries are not necessarily maintenance free, even from a mere compiling/building stand point (what if a patched indirect dependency no longer builds with new compilers...etc).

Is it bad form to patch a dependency? by BB_C in c/programming@programming.dev

[-] BB_C@programming.dev 3 points 5 days ago

This would depend on the language/ecosystem. It's worse for C and C++ than for example Rust because of packaging policies and ease of distributability.

Why is Rust so bare-bones? by BB_C in c/rust@programming.dev

[-] BB_C@programming.dev 30 points 2 months ago

Not sure if you're talking about the language, or the core/alloc/std libraries, or both/something in-between?

Can you provide specific examples, an which specific languages are you comparing against?

10

Wild linker v0.8 released (and updated benchmarks) (github.com)

submitted 2 months ago by BB_C@programming.dev to c/programming@programming.dev

0 comments fedilink

16

koto v0.16.0 released (koto is a scripting programming language) (github.com)

submitted 8 months ago* (last edited 8 months ago) by BB_C@programming.dev to c/programming@programming.dev

4 comments fedilink

36

[OC] Rust tops a diverse list of implementation languages in projects getting NLnet grants, Python 2nd, C is alive, and C++ is half dead! (programming.dev)

submitted 1 year ago* (last edited 1 year ago) by BB_C@programming.dev to c/programming@programming.dev

0 comments fedilink

https://nlnet.nl/news/2025/20250321-call-announcement-core.html

Notes

Projects meaningfully sharing two programming languages get 0.5 a point each, even if the split is not exactly half-half.
Two projects are listed under "Multi/Misc/Other" which is opinionated, and some may disagree with.
Three points (5 projects) are assigned to "Unaccounted/Not Available". Two of the projects have no code at all (related to the grant, or otherwise). One project with no published code is (charitably) listed under "Python", however, since the author mentions Python+QT as the choice for implementation.

1.5 (3 projects) C++

https://github.com/IObundle/iob-versat
(software part = 0.5, hardware is Verilog)
https://github.com/overte-org/overte
(0.5 C++, 0.5 JS)
https://kde.org/plasma-desktop
(grant is about mobile power management improvements, no idea about the code, but KDE/Plasma is C++, so charitable 0.5 for C++, 0.5 unaccounted)

1 Clojure

https://github.com/NyanCAD/Mosaic

1 Assembly

https://lib25519.cr.yp.to
(grant covers NEON vector implementation)

1 Haskell

https://github.com/ghc-proposals/ghc-proposals

1 Julia

https://github.com/PeaceFounder/AppBundler.jl

0.5 Shell

https://git.syndicate-lang.org/synit/synit
(0.5 rust, 0.5 shell)

2* Multi/Misc/Other

https://github.com/IObundle/iob-linux
(build project, a mix of python, Make, and C from OpenSBI)
https://unifiedpush.org
(specification for Android and D-Bus. Implementations in Go, C, Kotlin, and Flutter)

3* (5 projects) Unaccounted/Not Available

https://www.gnunet.org
(possible non-native Android yet to be written)
https://kde.org/plasma-desktop
(grant is about mobile power management improvements, no idea about the code but, KDE/Plasma is C++, so 0.5 for C++, 0.5 unaccounted)
https://nlnet.nl/project/LicenseCompatibilityAutomation
(no external link or specific info about the implementation)
https://librediagnostic.com
(fully unaccounted, site pages "under construction")
https://github.com/mapterhorn
(fully unaccounted, from org readme "Coming soon...")

21

[OC] Rust tops a diverse list of implementation languages in projects getting NLnet grants, Python 2nd, C is alive, and C++ is half dead! (programming.dev)

submitted 1 year ago by BB_C@programming.dev to c/rust@programming.dev

0 comments fedilink

https://nlnet.nl/news/2025/20250321-call-announcement-core.html

Notes

Projects meaningfully sharing two programming languages get 0.5 a point each, even if the split is not exactly half-half.
Two projects are listed under "Multi/Misc/Other" which is opinionated, and some may disagree with.
Three points (5 projects) are assigned to "Unaccounted/Not Available". Two of the projects have no code at all (related to the grant, or otherwise). One project with no published code is (charitably) listed under "Python", however, since the author mentions Python+QT as the choice for implementation.

9.5 (10 projects) Rust

https://git.joyofhardware.com/Products/FastWave2.0
https://github.com/slint-ui/slint
https://github.com/stalwartlabs/mail-server
https://github.com/dimforge
https://github.com/DioxusLabs/blitz
https://github.com/fdtshim
https://github.com/trynova/nova
https://github.com/yaws-rs
https://github.com/lycheeverse/lychee
https://git.syndicate-lang.org/synit/synit
(0.5 rust, 0.5 shell)

9 Python (8 + 1 project without code)

https://github.com/owasp-dep-scan/blint
https://github.com/web-platform-tests/wpt
https://github.com/niccokunzmann/open-web-calendar
https://git.xmpp-it.net/sch/Rivista
https://github.com/DataLab-Platform/DataLab
https://codeberg.org/IzzyOnDroid/rbtlog
https://gitlab.com/py3dtiles/py3dtiles
https://codeberg.org/flohmarkt/flohmarkt
https://rackweaver.app
(says python+qt, but no code yet)

6 (7 projects) C

https://mntre.com/sources.html
https://github.com/open-sdr/openwifi
https://wiki.musl-libc.org
https://github.com/LekKit/RVVM
https://github.com/skarnet/s6-rc
https://git.savannah.gnu.org/git/mes
(scheme interpreter, compiler + minimal libc in C = 0.5)
https://www.gnunet.org
(gnunet itself is C = 0.5, Anroid work would presumably use Java/Kotlin/Dart/... = 0.5 unaccounted)

3.5 (4 projects) TypeScript

https://github.com/cartesapp/cartes
https://github.com/edumeet
https://github.com/adorsys/open-banking-gateway
(0.5 Java, 0.5 TypeScript)
https://github.com/janeirodigital/sai-js
(grant is about specification work. But implementation is in TypeScript)

3.5 (4 projects) Java

https://github.com/slovensko-digital/autogram
https://github.com/igniterealtime/Openfire
https://github.com/MarginaliaSearch/MarginaliaSearch
https://github.com/adorsys/open-banking-gateway
(0.5 Java, 0.5 TypeScript)

3 Kotlin

https://github.com/florisboard/florisboard
https://github.com/EventFahrplan/EventFahrplan
https://github.com/tuskyapp/Tusky

2.5 (3 projects) Hardware/Verilog/...

https://github.com/opera-platform/opera-dsp
https://github.com/simple-crypto/SMAesH
https://github.com/IObundle/iob-versat
(hardware part = 0.5, software is C++)

2.5 (3 projects) Scheme

https://codeberg.org/spritely/goblins
https://nlnet.nl/project/SchemeTestingFramework
(no external link in grant page)
https://git.savannah.gnu.org/git/mes
(scheme interpreter, compiler + minimal libc in C = 0.5)

2.5 (3 projects) JavaScript

https://github.com/CycloneDX/cdxgen
https://github.com/overte-org/overte
(0.5 C++, 0.5 JS)
https://nlnet.nl/project/TALER-integration-Nuxt
(no external link)

2 Nix

https://nlnet.nl/project/Nix-ControlPlane
https://github.com/ibizaman/selfhostblocks
(no external link)

2 Go

https://github.com/namecoin/encaya
(namecoint-core is written in C++, but the grant is about encaya)
https://github.com/hockeypuck/hockeypuck

1.5 (3 projects) C++

https://github.com/IObundle/iob-versat
(software part = 0.5, hardware is Verilog)
https://github.com/overte-org/overte
(0.5 C++, 0.5 JS)
https://kde.org/plasma-desktop
(grant is about mobile power management improvements, no idea about the code, but KDE/Plasma is C++, so charitable 0.5 for C++, 0.5 unaccounted)

1 Clojure

https://github.com/NyanCAD/Mosaic

1 Assembly

https://lib25519.cr.yp.to
(grant covers NEON vector implementation)

1 Haskell

https://github.com/ghc-proposals/ghc-proposals

1 Julia

https://github.com/PeaceFounder/AppBundler.jl

0.5 Shell

https://git.syndicate-lang.org/synit/synit
(0.5 rust, 0.5 shell)

2* Multi/Misc/Other

https://github.com/IObundle/iob-linux
(build project, a mix of python, Make, and C from OpenSBI)
https://unifiedpush.org
(specification for Android and D-Bus. Implementations in Go, C, Kotlin, and Flutter)

3* (5 projects) Unaccounted/Not Available

https://www.gnunet.org
(possible non-native Android yet to be written)
https://kde.org/plasma-desktop
(grant is about mobile power management improvements, no idea about the code but, KDE/Plasma is C++, so 0.5 for C++, 0.5 unaccounted)
https://nlnet.nl/project/LicenseCompatibilityAutomation
(no external link or specific info about the implementation)
https://librediagnostic.com
(fully unaccounted, site pages "under construction")
https://github.com/mapterhorn
(fully unaccounted, from org readme "Coming soon...")

32

Koto: a simple and expressive programming language, usable as an extension language for Rust applications, or as a standalone scripting language (koto.dev)

submitted 1 year ago by BB_C@programming.dev to c/rust@programming.dev

7 comments fedilink

cross-posted from: https://programming.dev/post/23822190

I added this language to my watch list some time ago and forgot about it, until I got a notification about a new release (0.15) yesterday.

I'm someone who is familiar with system languages (C, Rust) and shell languages (Bash, Zsh, ..). But don't have much experience, at a proficient level, with any languages setting in between.

So I gave Koto's language guide a read, and found it to be very well-written, and the premise of the language in general to be interesting. I only got annoyed near the end when I got to @base, because I'm an anti-OOP diehard 😉

I hope this one well start to enjoy some adoption.

49

Koto: a simple and expressive programming language, usable as an extension language for Rust applications, or as a standalone scripting language (koto.dev)

submitted 1 year ago by BB_C@programming.dev to c/programming@programming.dev

12 comments fedilink

I added this language to my watch list some time ago and forgot about it, until I got a notification about a new release (0.15) yesterday.

I'm someone who is familiar with system languages (C, Rust) and shell languages (Bash, Zsh, ..). But don't have much experience, at a proficient level, with any languages setting in between.

So I gave Koto's language guide a read, and found it to be very well-written, and the premise of the language in general to be interesting. I only got annoyed near the end when I got to @base, because I'm an anti-OOP diehard 😉

I hope this one well start to enjoy some adoption.

Intel Arc B580 tested in five games on Linux; you’re better off sticking with an AMD GPU for now by BB_C in c/linux@programming.dev

[-] BB_C@programming.dev 28 points 1 year ago

What serious Linux users buy GPUs based on raw gaming performance on release week?

I personally buy based on open-source driver support. And this includes long-term active support, AND developer approachability.

My current GPU is an AMD/Radeon one because of that. But I'm reconsidering my position when my next hardware upgrade comes.

I reported an AMD GPU driver issue to mesa once. It was tested, confirmed, and patched by a competent AMD developer within a few days. Now you have easily reproducible issues like this not even going past the testing phase after many months. And there are similar issues across all model generations.

If I were to upgrade my workstation next year, I would probably go with an AMD CPU and an Intel GPU, which is the exact opposite of my current setup 🙃. One should never rely on outdated perceptions.

26

kdl 6.0.0-alpha.1 (first version with a KDL v2 implementation) (github.com)

submitted 2 years ago by BB_C@programming.dev to c/rust@programming.dev

3 comments fedilink

74

COSMIC ALPHA 1 Released (Desktop Environment Written In Rust From System76) (system76.com)

submitted 2 years ago by BB_C@programming.dev to c/rust@programming.dev

11 comments fedilink

archived link

Technically right…? by BB_C in c/software_gore@programming.dev

[-] BB_C@programming.dev 26 points 2 years ago

You should be thankful it's not 18446744073709551615 days to go.

Ladybird announcement by BB_C in c/linux@lemmy.ml

[-] BB_C@programming.dev 38 points 2 years ago

A reminder that the Servo project has resumed active development since the start of 2023, and is making good progress every month.

If you're looking for a serious in-progress effort to create a new open, safe, performant, independent, and fully-featured web engine, that's the one you should be keeping an eye on.

It won't be easy trying to catch up to continuously evolving and changing web standards, but that's the only effort with a chance.

10

cushy v0.3.0 Released (github.com)

submitted 2 years ago by BB_C@programming.dev to c/rust@programming.dev

1 comments fedilink

20

slint 1.6.0 Released (github.com)

submitted 2 years ago by BB_C@programming.dev to c/rust@programming.dev

2 comments fedilink

Examples are not Documentation by BB_C in c/rust@programming.dev

[-] BB_C@programming.dev 51 points 2 years ago* (last edited 2 years ago)

Examples ARE usage documentation.

What value is this blog supposed to be adding exactly?
The fact that top-level and API descriptive explanations are important?
The fact that some projects don't have complete documentation?
To whom exactly would this be considered new information?

Rust without crates.io by BB_C in c/rust@programming.dev

[-] BB_C@programming.dev 29 points 2 years ago

What’s interesting is that this problem is largely solved for C and C++: Linux distributions like Debian

[closes tab]