You now have a direct way for users to insert data into your repo, which can include illegal things. And if you're required to delete it later, you'll be forced to edit your git history.
Worrying about editing git history buries the lede. Any comment system allows users to insert data into your site, which, if it might be illegal things, is a legal risk.
and the wasted CPU and memory involved. Git is by no means a good design for a comment-system, it is overcomplicating it in ways previously unimaginable.
> Let's be honest, for a personal blog, >1k comments is an overestimate.
Maybe, maybe not. Before 2024, my blog got <10k views/y. Then in 2024 it got close to 1 million (this year it will likely be 100k). Very hard to predict traffic thanks to hn and stuff!
To my understanding, the only time CO2 emissions were down was during covid.
While there are a few localized success stories, I'm not aware we've actually meaningfully impacted our trajectory.
To be abundantly clear: it's true that eg. Trump's administration will have limited effect, mainly because it's a global thing ... But global emissions have been rising, too.
People have predicted peak CO2 multiple times, but it hasn't actually crystalized beyond the shutdown year to my knowledge.
I think we witnessed a profound paradigm shift last week - China is the new global driving force to avert climate catastrophy. The probably peaked CO2 output last year. Last yeear they reached their 2030 target for renewables as share of total energy production. Almost 60% of new cars sold there are electric. And China produced more PV cells in the first half of this year alone than have been installed in the US in sum, ever.
And now they stated a public CO2 reduction goal for the first time.
I suspect people in the US haven't really noticed this as much because the 100%+ tariffs on cars and PV isolate the country from the dramatic changes happening everywhere else. Here in Germany I can buy 2 kWp in panels plus an inverter for under 400€.
We can say the growth curve is not exponential, its now linear. At the most hopeful, we can say its plateauing and we will hit peak carbon emissions soon (some say we've already hit it).
But all that's modeling, there are too many variables to really know.
I think reality is a potentially a bit darker in that we really have impacted the trajectory, it is just grossly insufficient to have a meaningful change in the direction.
We now seem in the unfortunate place where we have kicked or are kicking off system dynamics that are going to cause a large scale reconfiguration of our life support system.
It's especially hilarious because ime, when it's drifting into this mode of constantly saying "production ready, ready to merge, ready to ship", the code it's producing is usually in a complete downward spiral - likely because it's no longer able to reason about the effect the "one little change" will have on the rest of the application.
Ive come to just terminate the session if a phrase like that turns up
Tbf to Nadia however, her comment supposedly came from the "code reviewer" agent? So the prompt might've explicitly asked it to make this statement and would (hopefully) not be reusing the context of the development (and neither the other way)
OP here (Nadia). Yes, in my case I was specifically asking for it to act as a code reviewer and make comments and a recommendation on whether to merge the PR with my changed into our main branch. This just happened to be the response.
I feel like Claude specifically uses language in what seems like a more playful way. I notice this also when instead of just a loader there are things like “Baking… Percolating…” etc.
I do get the ick if it feels like the agent is trying to be too “human” but in this case I just thought it was funny language for a response to my ask specifically to play a PR reviewer role.
Claude in reviewer mode also had a funny (at least to me) comment about it being interesting that Claude put itself as a PR contributor. I think in the screenshot in my blog post (if it got cutoff for others let me know and I can fix), but not called out in the text.
Most of my devices have had ways to turn them off.
Router has a button which disable all lights until it's pressed again, monitors have the setting in their menus.
The only device thats shining brightly in my home is a storage controller I've got in my home server, with no way of turning it off - or at least dimming it down
> you're aware that the space shuttle was "reusable" though, right?
Shuttle was reüsable on paper. It couldn’t unlock high-cadence launch because it was not built on an assembly line and had long, manual and error-prone refurbishment requirements.
Put practically, one couldn’t build a LEO constellation like Starlink or aim for in-orbit refuelling with the Shuttle. One can do the former with Falcon 9. One can attempt the latter with Starship.
I don't disagree, after all, the shuttles booster was(at least to my knowledge) more expensive them the reusable shuttle, but that's once again a qualifier to the statement that - without that qualifier, does continue to point to the shuttle.
> without that qualifier, does continue to point to the shuttle
The qualifier is only semantically meaningful. The engineering benefits one gets from reusability--low costs and high cadence--weren't there for the Space Shuttle.
The shuttle’s solid rocket boosters splashed down in the ocean via parachute, and were recovered and reused. The main engines and thrusters/rcs were also reused. Only the external tank was disposed. The issue with the shuttle (among many) was that the reuse was not actually economical due to the maintenance required between each launch.
I still feel like you're underselling the article however.
Is obviously ultimately parallelism, but parallelism is hard at scale - because things often don't scale - and incorrect parallelism can even make things slower. And it's not always obvious why something gets slower by parallelism.
As a dumb example, if you have a fictional HDD with one disk and one head, you have two straightforward options to optimize performance:
Make sure only one file is read at the same time (otherwise the disk will keep seeking back and forth)
Make sure the file is persisted in a way that you're only accessing one sector, never entering the situation in which it would seek back and forth.
Ofc, that can be dumped down to "parallelism", because this is inherently a question about how to parallelize... But it's also ignoring that that's what is being elaborated on: ways s3 used to enable parallelism
You're right if you're only looking at peak sequential throughput. However, and this is the part that the author could have emphasized more, the impressive part is their strategy for dealing with disk access latency to improve random read throughput.
They shard the data as you might expect of a RAID, 5, 6, etc array and the distributed parity solves the problem of failure tolerance as you would expect and also improves bandwidth via parallelism as you describe.
The interesting part is their best strategy for sharding the data: plain-old-simple random. The decision of which disks and at which sectors to shard the data is done at random, and this creates the best change that at least one of the two copies of data can be accessed with much lower latency (~1ms instead of ~8ms).
The most crude, simple approach turns out to give them the best mileage. There's something vaguely poetic about it, an aesthetic beauty reminiscent of Euler's Identity or the solution to the Basel Problem; a very simple statement with powerful implications.
The fractional part isn't helping them serve data any faster. To the contrary, it actually reduces the speed from parallelism. E.g. a 5:9 scheme only achieves 1.8x throughput, whereas straight-up triple redundancy would achieve 3x.
It just saves AWS money is all, by achieving greater redundancy with less disk usage.
I don't think you've ever talked with someone in manufacturing that's in any way aware how quality assurance works there...
I can understand how you might have that misunderstanding, but just think about it a little, what kind of minor changes can result in catastrophic failures
Producing physical objects to spec and doing quality assurance for that spec is way harder then you think.
Some errors are easy to spot for sure, but that's literally the same for AI generated slop
I spent five years working in quality assurance in the manufacturing industry. Both on the plant floor and in labs, and the other user is largely correct in the spirit of their message. You are right that it's not just up to things being easy to spot, but that's why there are multiple layers of QA in manufacturing. It's far more intensive than even traditional software QA.
You are performing manual validation of outputs multiple times before manufacturing runs, and performing manual checks every 0.5-2 hours throughout the run. QA then performs their own checks every two hours, including validation that line operators have been performing their checks as required. This is in addition to line staff who have their eyes on the product to catch obvious issues as they process them.
Any defect that is found marks all product palleted since the last successful check as suspect. Suspect product is then subjected to distributed sampling to gauge the potential scope of the defect. If the defect appears to be present in that palleted product AND distributed throughout, it all gets marked for rework.
This is all done when making a single SKU.
In the case of AI, let's say AI programming, not only are we not performing this level of oversight and validation on that output, but the output isn't even the same SKU! It's making a new one-of-a-kind SKU every time, without the pre and post quality checks common in manufacturing.
AI proponents follow a methodology of not checking at all (i.e. spec-driven development) or only sampling every tenth, twentieth, or hundredth SKU rolling off the analogous assembly line.
In the case of AI, it gets even worse when you factor in MCPs - which, to continue your analogy, is like letting random people walk into the factory and adjust the machine parameters at will.
But people won't care until a major correction happens. My guess is that we'll see a string of AI-enabled script kiddies piecing together massive hacks that leak embarrassing or incriminating information (think Celebgate-scale incidents). The attack surface is just so massive - there's never been a better time to be a hacker.
It depends entirely on what you’re building. The OP mentioned “humans fishing out faulty items” that would otherwise be built by artisans, so clearly we’re not talking complex items requiring extensive tests, but stuff you can quickly find and sort visually.
Either way, the point would stand. You wouldn’t have that factory issue then say “alright boys, dismantle everything, we need to get an artisan to rebuild every single item by hand”.
Cobol is used in pretty much all enterprise legacy systems.
But "used in" doesn't mean that it's actively being developed by more then a tiny team for maintaining it.
As this graph we're commenting on is mostly talking about popularity/most used it's never going to rate higher, because for every one Cobol dev there are more then 100 Java devs employed by the same company
That's a pretty wild claim. What's legacy for you? I'd consider legacy e.g J2EE crap running on web[sphere|logic] as holding most of the points in that league table vs COBOL.
A legacy software to me is whatever the company that employs me says is said legacy software.
Pretty much every business I've worked at to date has had such legacy software, which was inevitably still used in some contexts.
It's not always obvious, because - following with the previous example numbers - only 1-2 Java devs will have to interact with the legacy software again, hence from the perspective of the remaining 98, Cobol doesn't exist anymore.
You now have a direct way for users to insert data into your repo, which can include illegal things. And if you're required to delete it later, you'll be forced to edit your git history.
But if everyone behaves, it's a great solution
reply