I would love it if future folks can write their own random scripts without needing a developer to do it for them.
I would love to see more people writing software. There will always be advanced work that needs doing. There will always be larger challenges.
I want the world of the future, where every 10-year-old knows calculus and python and is incredibly capable, and then I want to see the future we get when they grow up.
Many projects have foundations or fiscal sponsors you can work with.
If you care about Python, you could support the Python Foundation, and/or hire or sponsor some Python developers. If you care about Rust, support the Rust Foundation, and/or hire or sponsor some Rust developers. If you care about Reproducible Builds, or QEMU, or Git, or Inkscape, or the future of FOSS licensing, or various other projects (https://sfconservancy.org/projects/current/), support Software Freedom Conservancy.
If you care about a smaller project, and they don't have a means of sponsorship, you could encourage them to accept sponsorship via some means, or join some fiscal sponsor umbrella like Conservancy.
Another such umbrella organization is Software in the Public Interest (SPI). Some of the more notable projects they sponsor include Arch Linux, Debian, FFmpeg, LibreOffice, OpenSSL, OpenZFS, PostgreSQL, and systemd.
> I think if you are a billion dollar company using these tools, sponsoring maintenance isn't a lot to ask.
It isn't a lot to ask, but it's challenging to 1) find who to ask, and 2) get them to care about the long-term view in a way that doesn't fit into short-term thinking and budgeting.
Security with io_uring is great these days. Many years ago it moved away from the original architecture that led to several security issues; its current architecture is no more prone to security issues than any other part of the kernel.
For context, the original architecture involved having privileged kernel-side offload processing that had to carefully drop privileges each time it did something on behalf of the userspace process. As you can imagine, that fail-insecure architecture was heavily prone to security holes.
io_uring got rid of that architecture years ago, in favor of running with the permissions of the userspace process. With that change, there's no longer any reason to consider io_uring any less secure than the rest of the kernel.
yea, just look at the state of many C projects. it's rather clearly worse in practice in aggregate.
should it be higher friction than npm? probably yes. a permissions system would inherently add a bit (leftpad includes 27 libraries which require permissions "internet" and "sudo", add? [y/N]) which would help a bit I think.
but I'm personally more optimistic about structured code and review signing, e.g. like cargo-crev: https://web.crev.dev/rust-reviews/ . there could be a market around "X group reviewed it and said it's fine", instead of the absolute chaos we have now outside of conservative linux distro packagers. there's practically no sharing of "lgtm" / "omfg no" knowledge at the moment, everyone has to do it themselves all the time and not miss anything or suffer the pain, and/or hope they can get the package manager hosts' attention fast enough.
C has a lot of characteristics beyond simple lack of a standard automatic package manager that complicate the situation.
The more interesting comparison to me is, for example, my experience on C# projects that do and do not use NuGet. Or even the overall C# ecosystem before and after NuGet got popular. Because then you're getting closer to just comparing life with and without a package manager, without all the extra confounding variables from differing language capabilities, business domains, development cultures, etc.
when I was doing C# pre-nuget we had an utterly absurd amount of libraries that nobody had checked and nobody ever upgraded. so... yeah I think it applies there too, at least from my experience.
I do agree that C is an especially-bad case for additional reasons though, yeah.
Gotcha. When I was, we actively curated our dependencies and maintaining them was a regularly scheduled task that one team member in particular was in charge of making sure got done.
most teams I've been around have zero or one person who handles that (because they're passionate) (this is usually me) - tbh I think that's probably the majority case.
exceptions totally exist, I've seen them too. I just don't think they're enough to move the median away from "total chaotic garbage" regardless of the system
Well, consider that a lot of these functions that were exploited are simple things. We use a library to spare ourselves the drugdery of rewriting them, but now that we have AI, what's it to me if I end up with my own string-colouring functions for output in some file under my own control, vs. bringing in an external dependency that puts me on a permanent upgrade treadmill and opens the risk to supply chain attacks?
Leftpad as a library? Let it all burn down; but then, it's Javascript, it's always been on fire.
> but now that we have AI, what's it to me if I end up with my own string-colouring functions for output in some file under my own control
Before AI code generation, we would have called that copy-and-paste, and a code smell compared to proper reuse of a library. It's not any better with AI. That's still code you'd have to maintain, and debug. And duplicated effort from all the other code doing the same thing, and not de-duplicated across the numerous libraries in a dependency tree or on a system, and not benefiting from multiple people collaborating on a common API, and not benefiting from skill transfer across projects...
Smells are changing, friend. Now, when I see a program with 20000 library dependencies that I have to feed into a SAST and SCA system and continually point-version-bump and rebuild, it smells a hell of a lot worse to me than something self-contained.
At this point, I feel like I can protect the latter from being exploited better than the former.
> At this point, I feel like I can protect the latter from being exploited better than the former.
I expect that your future CVEs will say otherwise. People outside your organization have seen those library dependencies, and can update them when they discover bugs or security issues, and you can automatically audit a codebase to make sure it's using a secure version of each dependency.
Bespoke AI-generated code will have bespoke bugs and bespoke security issues.
When most people say "ranked choice" they seem to refer to IRV, which is broken in multiple ways, but most notably that it has the property that ranking someone higher can make them lose and ranking someone lower can make them win. That happens because IRV ignores all of someone's preferences except their top choice, until their top choice is thrown out, at which point IRV looks at their next preference.
There are much better systems: approval (for simplicity, at the expense of more accurate preference information) and Condorcet (for accuracy, at the expense of making it more difficult to explain tie-breaker corner cases to the average person).
I would love it if future folks can write their own random scripts without needing a developer to do it for them.
I would love to see more people writing software. There will always be advanced work that needs doing. There will always be larger challenges.
I want the world of the future, where every 10-year-old knows calculus and python and is incredibly capable, and then I want to see the future we get when they grow up.
reply