Completely agree. I'd be tempted to put up some Rust code if the contribution pipeline wasn't such utter crap (yes yes it was good for it's time, but that was decades ago).
But I won't be putting up any code either way until the culture moves on from little kings calling things they don't like (and that don't really affect them) "cancer". I'm not holding my breath.
I've started wondering what's next after Linux because it doesn't feel sustainable long term any more. There's a small trickle of fresh blood but not enough to keep the kernel project healthy IMO.
> if the contribution pipeline wasn't such utter crap
I think the filter they have is working as intended, as demonstrated by this sentence. I'd agree the pipeline isn't the best, but it's not crap either, it evidently worked decades ago, and it also evidently works today, even though you seem to think it doesn't.
So in this case, they'd probably prefer contributors that can see the good and bad parts of a process, instead of a knee-jerk reaction to it calling it "crap", and prefer those contributors to be more amendable to existing workflows than many seem to want to be, as they've found their workflow to work (even if they aren't perfect).
> I'd agree the pipeline isn't the best, but it's not crap either, it evidently worked decades ago, and it also evidently works today, even though you seem to think it doesn't.
Given that the arcane state of tooling around the Linux kernel is a constant complaint in any "why do you not want to work on the Linux kernel" thread, the process evidently does not work, for it excludes many MANY MANY people from working on the Linux kernel.
At the moment, the kernel development process is mostly gatekeeping to keep moderation effort at bay - anyone running any major FOSS project on Github is all too aware of that - but in the end IMHO they're throwing the baby out with the bathwater, and by the time the lack of new people becomes too evident to ignore it will be too late.
Location: Edinburgh, UK / Worldwide
Remote: Yes
Willing to relocate: No
Technologies: Rust, EtherCAT
Résumé/CV: https://wapl.es/cv
Email: [email protected]
Need help with Rust in your EtherCAT deployment? I'm your guy! I'm available for contracting roles to help you implement or debug Rust EtherCAT applications using https://github.com/ethercrab-rs/ethercrab. I've helped various companies implement their first Rust control systems, as well as tune the base Linux installs for best realtime performance.
Location: UK/Edinburgh
Remote: Yes
Willing to relocate: No
Technologies: Rust (including no_std), EtherCAT
Résumé/CV: https://wapl.es/cv
Email: [email protected]
Hello! I'm James and I'm keen on working in robotics and automation. If you need help implementing industrial control systems in Rust, I'm your guy! I'm well versed in EtherCAT as author of EtherCrab[1] but can be of service for other protocols like Modbus, along with tuning Linux for realtime. Do get in touch!
Location: Scotland, UK
Remote: Yes, full remote
Willing to relocate: No, sorry
Technologies: Rust, EtherCAT, embedded Linux, microcontrollers
Résumé/CV: https://wapl.es/cv
Email: [email protected]
Senior Rust programmer with 6+ years working in the language full time, ranging from web backends to embedded Linux IoT services. I'm looking for Rust work either in industrial automation with EtherCAT or `no_std` and microcontrollers.
I'm the creator of EtherCrab (https://crates.io/crates/ethercrab), a pure Rust EtherCAT controller, borne out of frustration from the field of C/C++ implementations out there. Do you have a Rust automation application that needs EtherCAT? Let me know!
If not, maybe you're interested in hiring a `no_std` embedded Rust developer. I'd love to discuss a full time role if you're willing to take on a fast learner with a good hobby background in writing software for microcontrollers.
Built into `cargo`, I'd recommend `cargo tree`, `cargo tree -i` and/or `cargo tree --duplicates` to figure out where certain types of dependency tree bloat are.
We use it a bit for https://github.com/embedded-graphics/embedded-graphics and I have to say I love it. It's just the right balance between configuration variables/constants and "a folder full of bash scripts". I highly recommend giving Just a try.
reply