The word “exploit” may be doing a lot of work here. In my experience Opus 4.6 is perfectly happy to provide test cases that trigger ASAN, even without the super secret squirrel security access.
But if you ask it to get you a shell it’ll probably tell you to get lost.
I've regularly heard something similar said of consulting work, too. Many people new to the game worry about charging too much, because if a client is paying more then surely the pressure will be higher. Instead they end up experiencing the opposite: charging a higher rate tends to get them a better kind of client.
I'm not sure what the exact lesson is here. Something about stingy people not being nice to work with, perhaps?
Stingy people are indeed not nice to work with, which is why I raised my prices as a freelance coder through the roof about 20 years ago, usually pacing about triple the going market rate. But filtering out stingy people isn't the main factor in the phenomenon you're describing, because some of my happiest customers have been stingy people who capitulated to paying much more than they initially thought the work was worth. They tend to also be the ones who are most prone to congratulating themselves and bragging to their friends on springing for the most expensive option, and when they do, they invariably (even pathologically) need to assert to themselves and everyone else that they paid for "the best".
The name for this is the Veblen Effect [0], and it applies to all irrational market behaviour where people are actually happier with luxury goods the more they pay for them.
Funnily enough, I've seen some of the exact same clients brag about how cheaply they got something else. The lesson I've drawn is that they're mostly looking for approval, so they're equally interested in buying status as they are in getting real stuff done. It's a win/win if you deliver a great product that they can brag about, because they'll do the hard work of selling it to themselves for you.
A corollary of that psychology is that some, maybe even most people are never happy with stuff they paid market price for. They either think they could've gotten it cheaper, or they think they could have gotten more for their money. Paying market price makes them feel like a chump. But paying way more than market has to be justified to themselves first. It's simply too embarrassing to admit that they might have overpaid an arm and a leg. So as a contractor, pricing your work as either very cheap or very expensive, on the margins of the parabola, alleviates this vague sense of dissatisfaction from your clients' internal debate, and gives them the peace of mind that they're actually trying to buy.
Value is relative. Effort-to-income ratios vary significantly between traders.
The pragmatic accept that work ≠ value, some do so permanently. But someone newly aware of this may deem it unfair, and react with totally disproportionate demands, some do so permanently.
Then you come across those who already benefit greatly from the imbalance, yet still make disproportionate demands. These tend to be good at it, subtle, strategic. Which may explain why they end up on the benefiting side.
Broadly, you find three types: the greedy, the balanced, and the generous pragmatic.
The greedy exploits relativity. The balanced respects it. The generous navigates it without resentment. Whether consciously or not.
Not to mention that "OSI open source" is basically sponsored and advocated by the firms that stand to benefit the most: hyperscalers that will embrace, extend, and encrust the thing you built with their monetization tendrils and leave you without a way to make money on it yourself.
See: Redis, Elastic, etc.
Not an ounce of AWS or GCP is open source, yet they'll happily spin up a managed version of your thing and make hundreds of millions without cutting you in.
We need new licenses that are more "shareware" like. That permit individuals, but slap big trillion dollar companies.
"Fair source", "Fair code", the defold license, etc. are all pretty good.
I agree. Free Software is a good idea in concept, but it is the foremost reason there exist billion dollar tech monopolies today built on the free work of idealists worldwide.
In the age of LLMs and entitled users, I must be selfish and cannot release my work as free software any more. The best of all worlds, for me, is to provide source code along with binaries to paying customers.
Firecracker and gVisor are used by AWS and GCP, respectively, are open source. That's just off the top of my head, I'm sure there's more, there's also the whole Open Compute Project, after all.
They'll find loopholes around that too, in time - they already found some, which led to the SSPL being created.
What you actually want is some kind of noncommercial clause: you can use my free shit as part of your free shit. If you want to make money off my shit, the rules change to "fuck you, pay me"
"But what if a company just wants to try it out?" well they can live within the already existing exception called "not telling me you're breaking my license". If I don't know about it I can't impose any penalties on you. Every good business already knows how and when they can break the law with impunity, and that's one of them.
What are some good licenses for that? I generally do want fellow programmers to enjoy my work but I don't really want corporations finding ways to make trillions off of it and leaving me with nothing. I've been slapping AGPLv3 on everything I make for that reason. Any "open source" nonsense is just wealth transfer from well meaning developers straight into the pockets of corporations, so I picked the most copyleft license imaginable. I'm open to even stronger AGPLv3 alternatives. Anything that helps individual hackers and gets corporations to pay.
When I make open source software, it's a gift to the commons for the enrichment of all mankind. It doesn't cost me, or humanity, one bit if a big tech company benefits from it. The idea that companies shouldn't be able to benefit from contributions to the commons is not really justifiable.
> No, this begging is particularly different because it capitalizes on the good will of open source developers. Microsoft, Apple, and Google are standing on the internet in their trillion dollar business suits with a sign that reads "Starving and homeless. Any free labor will help." They aren't holding people up at gun point. Rather they hold out their Rolex encrusted hand and beg, plead, and shame open source developers until they get free labor.
> Once they get this free labor they rarely give credit. They're ungrateful beggars that take their donated work hours, jump in their Teslas, and ride off to make more trillions proclaiming, "Haha! That open source idiot just gave me 10 hours of free labor. What a loser."
Humanity benefits more if poor people can use it for free and big companies have to pay for it, than if both can use it for free. Companies having to pay for stuff is the only reason they don't have 100% of the money, which would be bad.
That was my experience. When I first started consulting 20 years ago I stupidly charged $40/hour because I was young and dumb I stupidly discounted the time it took to find clients (and things like health insurance, etc...). I quickly adjusted and started charging $120/hour. I got much better clients and the projects I worked on became that much more interesting.
In my experience charging too little is one of the biggest mistake to do when starting.
I don't think it's subconscious at all. If, for instance, you contract something on fiverr for $5, you expect $5 of work. If you contract something for $1000 you expect $1000 of work. And the former's probably going to take a lot more feedback to get to where you want than the latter.
Basically, you get what you pay for. That's not always true, but it holds pretty reliably.
Amazon, for example, charges us for cloud resources and then charges us again (handsomely) for the privilege of submitting bug reports to them. And then sometimes, even with a clear, deterministic repro for a bug with no plausible workaround (besides "stop using the feature"), where the fix is probably as simple as "pull a fix from upstream open source repo" or "sic Claude on it for 10 minutes", the bug remains open for literally years.
This is very different from "I didn't read the instructions on the screen and now I'm calling support". Both scenarios exist. I have some sympathy for businesses facing the latter, and much less for businesses facing the former.
Claude will answer all of those questions. The restriction Anthropic has is letting Claude pull the trigger and vibe-murder with no humans in the loop.
Or in case some folks find the addition of a computer confusing here, if someone sends you a physical letter and they've used correction tape or a black marker to obscure some parts of the letter, and you scratch away the correction tape or hold the letter up to a light source to read what's underneath, have you committed a crime?
I'm not a lawyer, so I don't know what the law has to say about this. But I do have at least a small handful of brain cells to rub together, so I know what the law _should_ say about this.
Precisely. If someone wants me to sign a contract on acceptable use of resources (like an agreement not to reverse engineer their software) they send me then that's another thing.
Absent that excluding other default protections like copyright, what I do with it should fall under the assumption of "basically anything".
If this were prior to 2021, I would say the CFAA could be violated so long as the property owner's _intentions_ were for that information to only be accessible to certain users. But I think the CFAA has been sufficiently reduced in scope after Van Buren v United States [0]
RDS, Route53, and Elasticache are decent, too. But yes, I've also been bitten badly in the distant past by attempting to rely on their higher-level services. I guess some things don't change.
I wonder if the difference is stuff they dogfood versus stuff they don't?
I once used one of their services (I forget which, but I think it was there serverless product) that “supported” Java.
… but the official command line tools had show-stopper bugs if you were deploying Java to this service, that’d been known for months, and some features couldn’t be used in Java, and the docs were only like 20% complete.
But this work-in-progress alpha (not even beta quality because it couldn’t plausibly be considered feature complete) counted as “supported” alongside other languages that were actually supported.
(This was a few years ago and this particular thing might be a lot better now, but it shows how little you can trust their marketing pages and GUI AWS dashboards)
I'm assuming you're talking about Lambda. I don't mess with their default images. Write a Dockerfile and use containerized Lambdas. Saves so many headaches. Still have to deal with RIE though, which is annoying.
Additionally, what has been the correct choice five years in a row might be catastrophically wrong in the sixth year. We need some randomness injected into our behaviour so that some people are always making "suboptimal" choices, to stop everyone from crowding into one local maximum and then getting swept away when the rare but inevitable flood comes along.
And with a little work you can even use them to map ranges of keys to values in a way that's reminiscent of interval trees — e.g. https://crates.io/crates/rangemap. (Disclosure: that's my crate.)
Nice! I was only suggesting considering BTrees because they also play nice with caches, instead of the more conventional binary tree balancing mechanisms.
This email is from a Debian maintainer, about Debian introducing a new hard dependency on Rust. It's not some random Rust advocate telling Debian folks that they should use Rust against their will.
Yes there are absolutely some obnoxious "you should rewrite this in Rust" folks out there, but this is not a case of that.
There are like 1000 Debian maintainers, right? This person doesn't speak for the project as a whole, and as far as I can tell he is telling Debian folks they will be accepting rust whether they want it or not, and whether their preferred architecture is supported or not. Maybe there was some organizational vote on this, but if so it isn't referenced in the thread. It says "I plan", not "Debian decided to".
And regardless, my point is it would be more sensible to say "I'm going to introduce an oxidized fork of apt and a method to use it as your system apt if you prefer" and then over the next year or so he could say "look at all these great benefits!" (if there are any). At that point, the community could decide that the rust version should become the default because it is so much better/safer/"modern"/whatever.
You seem to think of "rust enthusiasts" as some organized group with a goal of writing Rust for the sake of it. Rust is long past such extremely early adopter phase.
What you're seeing now is developers who are interested in writing a better version of whatever they're already working on, and they're choosing Rust to do it. It's not a group "Rust enthusiasts" ninjas infiltrating projects. It's more and more developers everywhere adopting Rust as a tool to get their job done, not to play language wars.
Nah, I called out redox and another commenter pointed out ripgrep as an even better example of what I’d prefer to see, and those are also by what I would call rust enthusiasts. I don’t think of them as a monolithic group.
Where we disagree is I would not call injecting rust into an established project “writing a better version”. I would love it if they did write a better version, so we could witness its advantages before switching to it.
They are referring to adopting the Sequoia PGP library, which is written in Rust. There are plenty of benefits to using Sequoia which you can investigate now, no need to theoretically wait for the integration to happen. Not coincidentally, the RPM package manager also adopted Sequoia PGP.
First off, the mail references far more rust adoption than just Sequoia, but since you bring it up: here is how RPM adopted Sequoia in Fedora-land. There was a proposal, a discussion with developers about the ramifications (including discussion about making sure the RPMs built on all architectures), and there were votes and approvals. Costs and benefits and alternatives were analyzed. Here's a page that has links to the various votes and discussion: https://fedoraproject.org/wiki/Changes/RpmSequoia
Can't you see how much more thought and care went into this, than is on display in this Debian email (the "if your architecture is not supported in 6 months then your port is dead" email)?
> my point is it would be more sensible to say "I'm going to introduce an oxidized fork of apt and a method to use it as your system apt if you prefer" and then over the next year or so he could say "look at all these great benefits!" (if there are any). At that point, the community could decide that the rust version should become the default because it is so much better/safer/"modern"/whatever.
That's not how open source software development works.
I wasn't asked by Linus whether ipchains should become the default over ipfirewall nor whether iptables should become over ipchains.
I wasn't asked whether GCC should use C++ instead of C as the language to build GCC itself.
I can go on with lots of examples.
Why should APT be different and require the maintainers to fork their own project do introduce changes? Why should an undefined "community" (who is that? apparently not the APT developers...) decide? Does this have to be done for every code change in APT?
ipchains is a perfect representation of what I want to see. They introduced it as an option alongside ipfirewall in 2.1, made it the default but allowed fallback to ipfirewall in 2.2, and removed ipfirewall in 2.4. That is a sane way to introduce a large breaking change. Not to mention they provided compatibility scripts to try to smooth over the user-side differences.
They certainly did NOT say "I'm replacing ipfirewall with ipchains in six months, and if your distro can't handle it you should sunset your distro."
It shouldn't be controversial to request a measured approach when making major changes to software lots of people depend on. That's part of the burden of working on important software. Note I'm not against apt or anything moving to rust.
If you think a situation where everyone had access to ipchains for 3 years to figure out how to migrate is similar to a situation where some architectures will be killed in six months without ever having had access to the new product then I don't know how to help you. What can affected ports do? Implementing a toolchain backend is a tall order.
We didn't talk about your gcc-to-c++ example, but if you read up on it you will know they took the pulse of affected developers, started experimental branches, made presentations, and made sure no architectures were left behind. All of which this Debian developer is failing to do.
Look I don't even disagree with the ultimate result... I don't think Debian needs to indefinitely support every strange port it has built up over the years. The way it's being done, though, doesn't sit right. There are far more mature ways to steer a big ship. Your own examples are showing the way.
My only source for this is personal experience, and no, I can't share any evidence of it.