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.
I've had an AI assistant send me email digests with local news, and another watching a cron job, analyzing the logs and sending me reports if there's any problem.
I'd say that counts as yes.
(For clarity: neither are powered by Claude Code Routines. Rather, Claude Code coded them and they're simple cron jobs themselves.)
Cumulative total number of deaths from Chernobyl, definitively the worst nuclear disaster in history, ranges from 4000 to 16000 (estimates, via Wikipedia). A dam bursting upstream of a few small towns will kill many more[0].
For comparison the Bhopal disaster (which is much less known in the West) that occurred on 3 December 1984 in Bhopal, Madhya Pradesh, India caused deaths in the range 3928 to 16000.
A government affidavit in 2006 stated the leak caused 558,125 injuries including 38,478 temporary partial injuries and approximately 3,900 severely and permanently disabling injuries.
Most of Europe drinks water from underground aquifers, which could not be affected by Chernobyl. Even breathing with air with radionuclides from Chernobyl in far distance from Chernobyl power plant didn't cause much radiation dose to the population. It was eating contaminated food and drinking contaminated milk that cause most radiation dose for population.
The precise mechanism was: radioactive particles fall to ground, or are washed to ground by rain, which concentrates them on vegetation with a lot of surface especially leafy vegetables, grass. Leafy vegetables are eaten directly by humans. Grass is eaten by cows, which again concentrates the radionuclides in milk. Humans drink milk, eat cheese concentrated from milk.
Not all radionuclides produced in nuclear fission have the same health impact on population in case of a nuclear disaster. To have a significant health hazard a radionuclide needs to have 3 properties: volatility, half-life, bioaccumulativity.
Volatility - some radioactive elements (heavy metals) are not moved far away by air, some radioactive elements like radioactive noble gases dilute very fast.
Stuff with a short half-life will transform into stable elements before migrating far. Stuff with with very long half-life will not produce much radiation during human lifetime.
Bioaccumulativity, radioactive stuff needs to stay in body to do damage. If it's eaten and then pooped out next day it usually doesn't cause much damage.
Most dangerous for general public in case of nuclear disasters are:
Iodine-131 (half-life 8 days): Iodine is stored in thyroid gland and stays in for long time in body. Especially children need a lot of iodine per kilogram of body weight. In regions where there is not enough of iodine in food (lacking seafood, table salt without added iodine), human body will try to get every bit of iodine from environment and hold it in body as long as possible.
Cesium-137 (half-time 30.04 years) : Alkali metal that forms salts. Has tendency to accumulate in soft tissues.
Strontium-90 (half-time 28.91 years) : Chemically similar to calcium. Has tendency to be incorporated into bones, teeth and stay in body for very long time.
Big part of radiation dose to the population could be prevented if the Soviet state didn't tried to cover up the Chernobyl and would prevent people from eating local food and milk, because most of the damage is done by eating iodine-131 in the first weeks after accident. Timely administration of potassium iodide tables would also help.
Chernobyl liquidators were affected with much broader range of radionuclides (radioactive stuff that did not migrate far) and with much high concentrations (radioactive stuff was not diluted much).
Direct deaths: 2 killed by debris (including 1 missing) and 28 killed by acute radiation sickness.
There many estimates about impact of Chernobyl disaster. I think the most comprehensive study is from Chernobyl Forum.
"On the death toll of the accident, the report states that 28 emergency workers died from acute radiation syndrome and 15 patients died from thyroid cancer. It roughly estimates that cancers deaths caused by the Chernobyl accident might eventually reach a total of up to 4,000 among the 600,000 cleanup workers or "liquidators" who received the greatest exposures."
Both are good sources of energy. If you're going to make the argument that "nuclear is unsafe so we shouldn't do it" though, it's relevant to keep in mind that since we've had nuclear power, dam failures have outpaced nuclear by many times in terms of deaths / TwH (1).
Edit to add: Before anyone jumps on for this it's important to note that without the Banquiao disaster the rates are about the same. Still means "nuclear is unsafe" is kind of a red herring.
"In August 1975, the Banqiao Dam and 61 others throughout Henan, China, collapsed following the landfall of Typhoon Nina. The dam collapse created the third-deadliest flood in history which affected 12,000 km2 (3 million acres) with a total population of 10.15 million, including around 30 cities and counties, with estimates of the death toll ranging from 26,000 to 240,000."
"After the disaster, the Chinese Communist Party and the Chinese government remained silent to the public, while no media were allowed to make reports."
"The official documents of this disaster were considered a state secret until 2005 when they were declassified."
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)
reply