Perhaps the rationale is laziness. Maintaining VM probably takes some more effort and competence than deploying to Vercel. Some people are willing to pay to minimize effort and the need to learn anything.
Vercel promises to engineer the pain away when it comes to deployment. The thing however is that Vercel introduced that pain in the first place by writing sub-par documentation and splitting many of NextJS functions into small parts with different cost.
> Well you did say your data is lost when a disk fails, which is not true.
Well, technically its still a possibility.
I am old enough to have seen issues with RAID1 setups not being able to restore redundancy, as well as RAID controller failures and software RAID failures.
Also, frankly you are being somewhat pedantic. My broader point was regarding cloud. I gave HD Failure as one example, randomly selected by my brain ... I could have equally randomly chosen any of the other items ... but this time, my brain chose HD.
Boot it up again. You'll still have higher availability than AWS, GitHub, OpenAI, Anthropic, and many others.
> Where do you think those object storage live exactly?
On a RAID5 array with hot-swappable disks, of course.
(Edit to add: this is just a comment on Kubernetes being invoked whenever someone talks about scalability; I have massive respect for what the TigerBeetle folks are doing)
> (Edit to add: this is just a comment on Kubernetes being invoked whenever someone talks about scalability; I have massive respect for what the TigerBeetle folks are doing)
Me too. Why did you have to add this edit though? Is there anything that suggests either of us disrespects the TigerBeetle folks? I swear, I'm going crazy.
> Security professionals who wish to use Opus 4.7 for legitimate cybersecurity purposes (such as vulnerability research, penetration testing, and red-teaming) are invited to join our new Cyber Verification Program.
This seems reasonable to me. The legit security firms won't have a problem doing this, just like other vendors (like Apple, who can give you special iOS builds for security analysis).
If anyone has a better idea on how to _pragmatically_ do this, I'm all ears.
If the vendors of programs do not want bugs to be found in their programs, they should search for them themselves and ensure that there are no such bugs.
The "legit security firms" have no right to be considered more "legit" than any other human for the purpose of finding bugs or vulnerabilities in programs.
If I buy and use a program, I certainly do not want it to have any bug or vulnerability, so it is my right to search for them. If the program is not commercial, but free, then it is also my right to search for bugs and vulnerabilities in it.
I might find acceptable to not search for bugs or vulnerabilities in a program only if the authors of that program would assume full liability in perpetuity for any kind of damage that would ever be caused by their program, in any circumstances, which is the opposite of what almost any software company currently does, by disclaiming all liabilities.
There exists absolutely no scenario where Anthropic has any right to decide who deserves to search for bugs and vulnerabilities and who does not.
If someone uses tools or services provided by Anthropic to perform some illegal action, then such an action is punishable by the existing laws and that does not concern Anthropic any more than a vendor of screwdrivers should be concerned if someone used one as a tool during some illegal activity.
I am really astonished by how much younger people are willing to put up with the behaviors of modern companies that would have been considered absolutely unacceptable by anyone, a few decades ago.
Not sure where the younger people thing came from, but I'm 45 and have been working in this industry since 1999. But even when I was in my 20s, I don't remember considering that I had a "right" to do something with a company's product before they've sold it to me.
In fact, I would say the idea of entitlement and use of words like "rights" when you're talking about a company's policies and terms of use (of which you are perfectly fine to not participate. rights have nothing to do with anything here. you're free to just not use these tools) feels more like a stereotypical "young" person's argument that sees everything through moralistic and "rights" based principles.
If you don't want to sign these documents, don't. This is true of pretty much every single private transaction, from employment, to anything else. It is your choice. If you don't want to give your ID to get a bank account, don't. Keep the cash in your mattress or bitcoin instead.
Regarding "legit" - there are absolutely "legit" actors and not so "legit" actors, we can apply common sense here. I'm sure we can both come up with edge cases (this is an internet argument after all), but common cases are a good place to start.
You cannot search for bugs or vulnerabilities in "a company's product before they've sold it to you", because you cannot access it.
Obviously, I was not talking about using pirated copies, which I had classified as illegal activities in my comment, so what you said has nothing to do with what I said.
"A company's policies and terms of use" have become more and more frequently abusive and this is possible only because nowadays too many people have become willing to accept such terms, even when they are themselves hurt by these terms, which ensures that no alternative can appear to the abusive companies.
I am among those who continue to not accept mean and stupid terms forced by various companies, which is why I do not have an Anthropic subscription.
> "if you don't want to give your ID to get a bank account, don't"
I do not see any relevance of your example for our discussion, because there are good reasons for a bank to know the identity of a customer.
On the other hand there are abusive banks, whose behavior must not be accepted. For instance, a couple of decades ago I have closed all my accounts in one of the banks that I was using, because they had changed their online banking system and after the "upgrade" it worked only with Internet Explorer.
I do not accept that a bank may impose conditions on their customers about what kinds of products of any nature they must buy or use, e.g. that they must buy MS Windows in order to access the services of the bank.
More recently, I closed my accounts in another bank, because they discontinued their Web-based online banking and they have replaced that with a smartphone application. That would have been perfectly OK, except that they refused to provide the app for downloading, so that I could install it, but they provided the app only in the online Google store, which I cannot access because I do not have a Google account.
A bank does not have any right to condition their services on entering in a contractual relationship with a third party, like Google. Moreover, this is especially revolting when that third party is from a country that is neither that of the bank nor that of the customer, like Google.
These are examples of bad bank behavior, not that with demanding an ID.
With the bank example, I thought your comment had some anti KYC language so I mixed it up with another response, sorry for the confusion.
I actually kind of agree with you in some principle, IF we had no choice. Like the only reason I can say “you can choose not to purchase this product” is because that is true today, thanks to competition from commercial and open source models.
But I’d be right there with you on “someone needs to force these companies to do ____” if they were quasi monopolies and citizens needed to use their technology in some form (we see this with certain patents around cell phone tech for example)
> If someone uses tools or services provided by Anthropic to perform some illegal action, then such an action is punishable by the existing laws and that does not concern Anthropic any more than a vendor of screwdrivers should be concerned if someone used one as a tool during some illegal activity.
In civilised parts of the world, if you want to buy a gun, or poison, or larger amount of chemicals which can be used for nefarious purposes, you need to provide your identity and the reason why you need it.
Heck, if you want to move a larger amount of money between your bank accounts, the bank will ask you why.
Why are those acceptable, yet the above isn't?
> I am really astonished by how much younger people are willing to put up with
Your examples have nothing to do with Anthropic and the like.
A gun does not have other purposes than being used as a weapon, so it is normal for the use of such weapons to be regulated.
On the other hand it is not acceptable to regulate like weapons the tools that are required for other activities, for instance kitchen knives or many chemicals, like acids and alkalis, which are useful for various purposes and which in the past could be bought freely for centuries, without that ever causing any serious problems.
LLMs are not weapons, they are tools. Any tools can be used in a bad or dangerous way, including as weapons, but that is not a reason good enough to justify restrictions in their use, because such restrictions have much more bad consequences than good consequences.
> Unsure where you got the "younger people" from.
Like I have said, none of the people that I know from my generation have ever found acceptable the kinds of terms and conditions that are imposed nowadays by most big companies for using their products or their attempts to transition their customers from owning products to renting products.
The people who are now in their forties are a generation after me, so most of them are already much more compliant with these corporate demands, which affects me and the other people who still refuse to comply, because the companies can afford to not offer alternatives when they have enough docile customers.
Reading through the comments here, most use cases is running an agent with some input in a cron job.
Anthropic now have Routines in Claude Code that do precisely that, and I’d bet they will bring that to Cowork. ChatGPT can’t be far behind (or maybe they already have - tbh hard to keep track of everything).
Devs can already set up reliable cron jobs for cheaper. Normies will have a less brittle solution for it soon. Where does that leave the claws?
If there’s no copyright, there’s no closed source. You get their code, decompile/disassemble and reuse as you see fit.
You might argue that doesn't help much if they never distribute that code (only runs on their servers). Here’s the inconvenient truth: GPL already allows that. Anyone can take a GPL codebase, do any modifications they want, run it forever, and never contribute back. You’d need AGPL to forbid that. GPL is only concerned if you further distribute the modifications.
And how does that exactly stop Amazon, Google or Microsoft (heh) from running GPLd software in their data centers and raking in money for hosting products built by poor open source devs?
I'm not worried about Microsoft recompiling bash and redistributing it. Is that a realistic problem for you?
Awesome. If you think that is stopping anyone, here's a challenge for you:
GNU Bash is GPL. You can run Bash (and many other Linux commands) in Windows through Windows Subsystem for Linux. In fact, WSL is a nice example of Microsoft doing embrace & extend.
The challenge: find the Microsoft's published code for Bash.
WSL does not include bash. When you use bash from within WSL, it is using the version of bash that was included in the upstream distribution of linux you have installed. If you are using a Debian based image, to get the source code run the following:
My point exactly (notice I didn't say MS distributes bash - it doesn't, as you pointed out).
Bash being GPL doesn't stop MS from benefiting from it by providing it to WSL users which make WSL more valuable for them. It also (as we talked in the other comment) doesn't prevent Amazon from running a database and charging people for it.
So what's this great advantage of GPL that it would make it worthwhile to keep the entire copyright system just so we could still have GPL?
If you dig around in its origin, GPL was concieved as a tool to "fight system from within system". If there's no system, you don't have to fight the system.
Then why did you ask for something if you knew it didn't exist???
Overall I think you are mistaken about the purpose of the GPL. It does not, nor has it ever intended to prohibit commercial activities. RMS and FSF have been pretty clear about this for many decades. And in fact, they are against the idea of licenses that prohibit commercial use.
The reason that large successful projects like Linux are so capable is not because it has a price tag of zero (and it often does not), but because of the feedback loop created by the viral-nature of the software license.
The vast majority of Linux is not a volunteer project -- but software developed by commercial software engineers who are being paid by a company to write software. Before copyleft, the idea that they would voluntarily share source code was laughable. The only reason they do is because they are legally required to do so.
This viral nature of copyleft creates a positive feedback loop:
1. Company uses software because it is free and solves a problem
2. they need a modification so they make it
3. they contribute back to the project because it is required by the copyright license
4. the project becomes more valuable at solving more problems that other companies have
5. Go to step 1
Breaking this feedback loop would put companies back to their natural state of not sharing. The result is that the software landscape would start to look a lot like the 80s and 90s again.
Without copyright, copyleft would not exist. And without copyleft, Linux would have been a hobby OS that died out in the early 90s. We'd be using things like Windows Server, Unix, etc. And to protect their business in the absence of copyright, they'd have heavy DRM schemes, obfuscation, cryptographic licensing, etc.
This entire comment is completely backwards. Linux gained momentum first, then it was adopted by the wider industry.
It's much easier to upstream your desired changes than maintain a separate fork (closed or otherwise) long-term. Additionally, many of the contributors have been using it for own servers, not required to contribute back.
Things like NVidia and other closed drivers show you can bolt a non-open part to the GPL code if you try enough.
> And without copyleft, Linux would have been a hobby OS that died out in the early 90s. We'd be using things like Windows Server, Unix, etc.
This ignores the entire existence of FreeBSD, NetBSD, OpenBSD.
> they'd have heavy DRM schemes, obfuscation, cryptographic licensing
This ignores the existence of heavy DRM schemes, obfuscation, kernel-level anticheat spyware, criminalisation of copyright-circumvention schemes, etc.
At this point, I think you're just trolling, so I'll stop here.
> It's much easier to upstream your desired changes than maintain a separate fork (closed or otherwise) long-term. Additionally, many of the contributors have been using it for own servers, not required to contribute back.
Then why is ~75% of the kernel from corporate commits today? You think large tech companies just started to become coincidentally generous with the advent of Linux?
> This ignores the entire existence of FreeBSD, NetBSD, OpenBSD.
The BSD are quite niche in install base and highly rely on GPL'd ports from Linux.
And, by far the most popular OS in the BSD family tree is MacOS, which is primarily closed source.
> This ignores the existence of heavy DRM schemes, obfuscation, kernel-level anticheat spyware, criminalisation of copyright-circumvention schemes, etc.
I'm not ignoring it, I'm telling you that would be more common, if you remove the all of the other mechanisms by which a company could choose. Without any legal controls whatsoever, the only option to control the use of a company's software would be through technical means. Removing other options would be incentivizing this.
Not sure if you're aware, but it's the labels, not Spotify:
> It pays roughly two-thirds of every dollar it generates from music, with nearly 80% allocated to recording royalties and about 20% to publishing, though how much artists and songwriters ultimately receive depends on their agreements with rights holders, which Spotify does not control. [0]
Spotify is frantically trying to escape the record label's death grip (hence podcasts), because they know they can squeeze it for just about anything with licensing deals. It's a terrible business model! Spotify keeps a third for their costs (& finally some profit in the past year or two), ie. about the same that Apple takes from App Store for basically nothing[1].
How the record labels convinced the world that Spotify is the bad guy here is beyond belief.
Wow. This is certainly a take. Two things:
1. Spotify has had a policy for a couple years now of not paying artists who generate less than 1,000 streams per year PER song. So if I get 999 streams on each of my 50 songs every year, I get nothing from Spotify.
2. Major labels own major stakes in Spotify. They are one and the same.
Ad. 1, I’m not saying Spotify is perfect, though in this case I would not be surprised if the algorithm was mandated by the record labels as the industry standard.
Ad 2, you’ll be surprised to hear the labels only held cumulative 20% stake up to the IPO and all of them subsequently wound it down. Their stake is now insignificant.
However, they had, have, and will always have, enormous leverage due to licensing-they’re monopolists and Spotify can either agree to whatever the terms are, or shut itself down.
Imagine if Netflix never started producing original content. They’d be at mercy of others or, more probably, already dead. Music doesn’t work that way and Spotify can’t just generate a bunch of pop hits to avoid paying the labels. They are trying to do that with podcasts.
Spotify here is the victim as much as the artists.
> Not sure if you're aware, but it's the labels, not Spotify:
*not only Spotify
They had plenty of problems from people abusing their system to steal listens from actual artists.
Their system is basically "one big bucket of listens" - if your song gets listens, you get money. So if you pay your sub, and listen to say 5 niche musicians only, it still all goes mostly to the most popular songs.
Now you might already notice the flaw here - if you say, make a bunch of bots that just listen to songs to boost their revenue, not only your sub doesn't pay artists you listen, but also to fraudulent ones.
Then there was problems with using fake collaboration tags, AI music to hijack artist profiles, and few others.
> Their system is basically "one big bucket of listens" - if your song gets listens, you get money. So if you pay your sub, and listen to say 5 niche musicians only, it still all goes mostly to the most popular songs.
That's basically how radio is accounted for in royalties, as well.
With Spotify knowing exactly who listened to what, it could be more precise (and arguably more susceptible to the fraud), but tbh what they do is standard (compulsory licensing) industry practice.
With radio, everyone that listens to a particular station is listening to roughly the same mix of songs, and they're "paying" (by listening to ads) on a per-hour basis.
If either of those was true with spotify, the unfairness would go away.
But when different listeners are paying very different amounts per hour, any correlation between payment amount and preferred content causes problems.
Whenever an actual artist reveals their earnings, it’s absolutely pitiful.
A quick search suggests a very steep drop off from the top earners.
‘At 100 million streams, artists can earn approximately $300,000-$500,000 in gross royalties. However, the actual amount reaching the artist varies dramatically based on their contracts. Major label artists receive $90,000-$150,000 after the label’s cut, while independent artists could keep $255,000-$425,000 after distributor fees.’
https://rebelmusicz.com/how-much-do-artists-make-on-spotify/
I think most of us are ending up with a similar workflow.
Mine is: 1) discuss the thing with an agent; 2) iterate on a plan until i'm happy (reviewing carefully); 3) write down the spec; 4) implement (tests first); 5) manually verify that it works as expected; 6) review (another agent and/or manually) + mutation testing (to see what we missed with tests); 7) update docs or other artifacts as needed; 8) done
No frameworks, no special tools, works across any sufficiently capable agent, I scale it down for trivial tasks, or up (multi-step plans) as needed.
The only thing that I haven't seen widely elsewhere (yet) is mutation testing part. The (old) idea is that you change the codebase so that you check your tests catch the bugs. This was usually done with fuzzers, but now I can just tell the LLM to introduce plausible-looking bugs.
No /s here so just in case this is a serious point:
Agile is a set of four principles for software development.
Scrum is the two-week development window thing, but Scrum doesn't mandate a two week _release_ window, it mandates a two week cadence of planning and progress review with a focus on doing small chunks of achievable work rather than mega-projects.
Scrum prefers lots of one-to-three day projects generally, I've yet to see training on Scrum that does not warn off of repeatedly picking up two-week jobs. If that's been your experience, you should review how you can break work down more to get to "done" on bits of it faster.
All good points here (and yeah I didn't add /s, hopefully "now you know!" was sufficiently obvious over-the-top).
All that said, in most orgs I've worked with, they were following agile processes over agile principles - effectively a waterfall with a scrum-master and dailies.
This is not to diss the idea of agile, just an observation that most good ideas, once through the business process MBA grinder, end up feeling quite different.
> All that said, in most orgs I've worked with, they were following agile processes over agile principles - effectively a waterfall with a scrum-master and dailies.
In my experience, they're all waterfall in scrum skin, except they also lose the one thing that was a strength of the old-school method: building up a large, well thought out, thoroughly checked spec up front.
So in the end, "business process MBA grinder" reshapes any idea to adapt to leadership needs - and so here, Agile became all about the things that make software people predictable cogs in the larger corporate planning machine. They got what they need anyway, but we threw away the bits that were useful to us.
Everything runs fine locally until you try to deploy it, and bam you need 4g ram machine to run the thing.
So you host it on Vercel for free cause it's easy!
Then you want to check for more than 30 seconds of analytics, and it's pay time.
reply