> Open source code library cURL is removing the possibility to earn money by reporting bugs, hoping that this will reduce the volume of AI slop reports.
> cURL has been flooded with AI-generated error reports. Now one of the incentives to create them will go away.
Why? If it is a purely machine generated report there is no need to have dozens of third parties that throw them around blindly. A project could run it internally without having to deal with the kind of complications third parties introduce, like duplicates, copy paste errors or nonsensical assertions that they deserve money for unrelated bugfixes.
A purely machine generated report without any meaningfull contribution by the submitter seems to be the first thing you would want to exclude from a bug bounty program.
Not necessarily. Reviewing an issue report is already enough time. Reviewing a patch is even more developer time.
The problem they had before was a financial incentive to sending reports, leading to crap reports that wasted time to review. Incentivizing sending reports + patches has the same failure mode, but they now have to waste even more time to review the larger quantity of input.
Anyway, for most cases I'd bet that Daniel can produce and get reviewed a correct patch for a given security bug quicker than the curl team can review a third-party patch for the same, especially if it's "correct, but ai-written".
I've read this idea that we could make people pay for security reports a few times here on HN (and you get back the money if the report is deemed good). That feels very wrong.
If I find a security issue, I'm willing to responsibly disclose it, but if you make me pay, I don't think I will bother.
Punishing bad behavior to disincentivize it seems more sensible.
For a person finding bugs for a living, an up-front fee to have their report reviewed by a maintainer would amount to an investment towards receiving a bug bounty if their report is valid and valuable. Just the cost of doing business.
It would discourage drive-by reports by people who just happened to notice a bug and want to let the maintainers know, but I think for a project that's high-profile enough to be flooded by bogus bug reports, bugs that random users just happen to notice will probably also get found by professional bug hunters at some point.
Only if the system is fair. If I as a maintainer want to scam I can just close the report as invalid, collect the $$$. Then a week latter I fix the issue with a commit that looks like it is unrelated.
I wouldn't do the above, but it is easy to see how I could run that scam.
You can look at how the maintainer dealt with previous bug reports to decide whether you can trust them or not. If there haven't been any previous bug reports but they nonetheless ask for a fee to help deal with the large volume of bug reports, yeah, that might be a scam. If you're running their software, maybe also check whether it's full of malware.
Good scammers pay out once in a while. Casinos hate it when everbody body loses, and love it when one person wins big - they need just enough losers to make money while enough winners to show off.
I get what you're saying, but I don't think punishing bad behavior is practical here. It's like a "enumerating badness" problem - there's way more bad actors with nothing to lose and not much practical way to punish them. There's too many of them and they all have no reputation to damage.
Not saying I have a better solution, just that it's a hard problem. Maybe dissuading some good people who have genuine security issues but don't feel like paying just has to be a cost of doing business.
Punishing bad behaviour does close to nothing, because the problem at hand is one of high asymmetry between the low effort to submit vs the high effort to review. I do agree that paying for reports isn't ideal, and we should find other ways to level the playing field, but in the meantime I haven't heard of anything as effective.
> the problem at hand is one of high asymmetry between the low effort to submit vs the high effort to review
Hence the threat to shame publicly I suppose.
Actually, Daniel Stenberg previously responded to this proposal the same way as me [1] (and maybe would still do). Coincidentally, I was reading your answer at about the same time as this part of the talk.
That sounds wonderfully meritocratic, but in the real world, a machine generating it is a very strong signal that it's bullshit, and the people are flooding maintainers using the machines. Maintainers don't have infinite time.
And the end of their self hosting offerings (Server, Data Center), which is currently driving a lot of people towards XWiki, for other reasons than money. XWiki SAS being mainly in Europe makes it attractive to EU users too.
> do you have any migration tips?
I don't have specific migration tips. I hope the docs are complete enough!
The Confluence Migration Toolkit is based on the Confluence XML module you found, but it adds a nice and convenient UI, converts some more macros that XWiki SAS sells, there's support, and there's consulting for larger migration projects or projects with special requirements.
(note: despite some paying features, everything is open source)
(disclaimer in case it was not obvious, I work for XWiki SAS)
Absolutely. If you want to even pretend to care about the environment, the very first step is starting to buy almost everything over $100 second hand. The added benefit is that it has lots of other societally positive effects! It has one of the very highest "sacrifices made vs. societal benefit" ratios there is. Please stop buying "environmentally friendly" gadgets and equipment and start buying "unfriendly" ones second-hand. There are very few categories of products where the efficiency gains made over the last decade mean you should buy new. Certainly less than 1% of purchases we make.
You're providing income to someone whose almost definitely more constrained than you. Without you, no one may have bought it. And the other comment is right - it's a buyers market, we need more buyers, there's a surplus of sellers. Another thing - if sellers more quickly and more easily get to sell their stuff second hand thanks to you, they're more incentivized to sell more in the future as well instead of keeping it in a drawer or throwing it in the trash.
That's right, and buying new and taking very good care of your stuff + using to the point of being unusable probably beats serial-buying second hand devices you mistreat.
There has to be second hand users tough, otherwise the second hand devices that, for a reason or another, are not used to the end by their original buyer never get used again.
> If one did wish to use Singularity for nefarious purposes, however, the code is MIT licensed and freely available — using it in that way would only be a crime, not an instance of copyright infringement.
Too bad the author picked the MIT license. Had they picked (A)GPL, it would have forced the criminals to distribute a copy of LICENSE.TXT alongside their improved copy of the source code on systems they compromise. Failing this, using it in that way would be both a crime and an instance of copyright infringement.
Although, it occurs to me that if they don't give credits to the original author, it's also already a copyright infringement under the MIT.
If I might interject for a moment, you should've recommended the (A)GPLv3.
The anti-tivoization clause in Version 3 would allow users to modify and replace the rootkit with their own, more or less malicious version, even if it would otherwise violate copyright law.
It's nice until you get spammed with emails from angry users. I think it happened to the sqlite and other popular open source project authors. Non technical users think they are polluting their computer.
The person in that thread could explain the situation a lot more better to the non technical users. You could do this:
"I don't know what happened to your computer but you seem to be saying someone hacked your computer and installed some software and you found acme.com mentioned on it. This was not done by me. acme.com is open source software that is freely available to anyone. This is the same as if someone installed software on your computer that mentions the google chrome web browser - that would not indicate google had anything to do with that action, since google chrome is freely available too."
This is why our temp files have names like malware_dropper.exe and bitcoin_scam.xls. If anyone sees those they assume it's some virus and don't bother us with them.
It's just like a gun free zone. You glue a prominent sign to your laptop that uses bright colors and an imposing font. "No proprietary software permitted!" Problem solved.
i think this comment is referring to the uniquely american controversy over "gun free zones", ie zones where... you aren't allowed to carry firearms by law, often marked with a sign
which i find very entertaining, saying "a sign can't stop a criminal!" as if that's not the case with any law enforced via threat of criminal prosecution
I don't think I'd call it a controversy exactly. There are places where the signs make sense (ex court buildings) and then there are places where they are purely performative. When a school in the ghetto that suffers gang related violence prominently posts such signs they rightfully get made fun of. Meanwhile most schools (at least where I grew up) either don't bother to post such signs or only post a subdued "all weapons illegal" near the entrance (that includes even pocket knives BTW it's not just a gun thing).
Another great one is "drug free zone" seen plastered all over a seedy highschool. Drugs are blanket illegal everywhere here. The US has made an art form out of persecuting drug users. We've peddled our "war on drugs" globally. What could possibly be the point of posting such a sign?
> I guess only people writing code manually will be "frontier".
Personally, I believe that seems almost inevitable. Ever since Sonnet 3.5 came out, my assumption has been that most devs will either need to become largely product people, or find a new career.[0] I mean, most devs have been implementing known patterns most of the time, right? That seems on track to be completely replaced by agentic dev tools, does it not?
The best terms for this new role I can think of are "Product Developer," or "Software Product Developer." This is a product-minded person who is able to create non-frontier software using agentic dev tools.
What I am really curious about is if devs at the frontier will be more, or less likely, to publish their work as open source in the future.
[0] I think there has been a clear divide here in excitement regarding agentic dev tools along these lines. Product-minded devs are really into the new tools. Non-product minded, more code-driven devs seem to be far less excited.
> Here’s the question a lot of developers are sitting with: do we lose some of our cognitive abilities if we’re reduced to reviewers? If we’re not writing the code, are we still thinking deeply about the problems? Or are we reduced to pattern-matching against LLM output, slowly atrophying the muscles we spent years building?
No, absolutely not. Please don't start to think that by not doing stuff on your own, you miss out on keeping yourself sharp and trained and on improving in this stuff.
If developers who have adopted LLMs for writing code start to think this, that might scare away some from using LLMs at all, and this weakens my evil plan to make a lot of money fixing their code with my intact coding abilities, especially when these LLM tools are going to get crazy expensive because at some point they will need to be sustainably funded, when I'll still be somewhat affordable in comparison. I'd rather get rich quick by doing the same thing I've been doing for years, don't take this from me please.
Haha. I can totally see a future where business hire outside consultants to fix in-house AI developed code and to train developers on AI pitfalls.
May be the design will be outsourced to consultancies and then implementation using AI is left to in house talent. May be new recommendation and lists like OWASP top 10 and 12 factors will emerge for AI too.
In case you missed them: check out querySelector and querySelectorAll. They are closer to what the jQuery selector system does, and I think they were inspired by it.
If the verbosity bothers you, you can always define an utility function with a short name (although I'm not personally a fan of this kind of things).
body.qsa('.class').forEach(e=>):
Yes, add qs() and Array.from(qsa()) aliases to the Node prototype, and .body to the window, and you’ve saved yourself thousands of keystrokes. Then you can get creative with Proxy if you want to, but I never saw the need.
Agree if you've a library developer. If you're an app or website developer then it's your project. Everyone else should steer clear of adding to native prototypes, just so they are clean for the end user.
If you are an app or website developer, at least you won't break other's systems.
But you might still break stuff in your own projects. Imagine you extend a native prototype with a method, and later the native prototype starts having a method with the same name.
Newer libraries start using that new standard method.
You upgrade the libraries your website depends on, or add a dependency, and this new code happens to depend on that native prototype. Only you replaced it with your custom method, and that method likely doesn't have the exact same behavior. You broke that new code and fixing this might not be trivial because uses of your custom method are sprinkled everywhere in your code.
It only works if you ever works on projects that have zero dependencies, or dependencies you never update.
Or you could spare yourself the troubles and define a method that takes the node in parameter.
It's also a question of forming good habits: you could be working on your projects now, forming a habit of extending prototypes, but will you remember not to do this the day you write a library?
By the way, how can you be sure you won't move some of your app code to a library because you like your utility functions and would like to reuse them in another project of yours? And why not open source that shared code, so you can just install it with NPM? Bam, that stuff is a library now.
> You upgrade the libraries your website depends on, or add a dependency, and this new code happens to depend on that native prototype. Only you replaced it with your custom method, and that method likely doesn't have the exact same behavior. You broke that new code and fixing this might not be trivial because uses of your custom method are sprinkled everywhere in your code.
He was suggesting adding a prototype method, not replacing one. Unless the library your using is also adding prototypes, I can't think of an issue with this. Sure, if a new version of JS ends up using these names then things could break, but I'd bet this won't cause him a problem in actuality.
Thanks for the feedback. But you did recommend a method that takes the node as a parameter. What protects me from that method name being claimed by some library later in the exact same way?
I used to use prototype (and sometimes scriptaculous)... Then came IE8 and broke the world on me.
For anyone that didn't know, IE8 implemented native JSON.(parse/stringify) methods, and the second parameter is a hydrator/dehydrator... however, if you added custom properties/methods to Array or Object prototypes, they would throw an error you couldn't catch in JS... so to work around, you'd have to load the JSON library and use it under a different name, in ALL your code, because the native implementation was locked/sealed and couldn't be masked out.
Second most annoying IE bug was 5.0.0 and the old/new api's for dealing with select elements. New worked, old broken, have fun.
> Open source code library cURL is removing the possibility to earn money by reporting bugs, hoping that this will reduce the volume of AI slop reports.
> cURL has been flooded with AI-generated error reports. Now one of the incentives to create them will go away.
[1] https://news.ycombinator.com/item?id=46701733
[2] https://etn.se/index.php/nyheter/72808-curl-removes-bug-boun...
reply