I'm unsure what SpaceX's weighting would be in QQQ but with Tesla being <3.54% weighting it would take both companies being 0s within a year to offset the cost in taxes from reweighting...
Candidly, while I understand the need for some amount of redundancy, I'm curious what this level of redundancy adds in terms of complexity to the system of a whole and whether or not that complexity-add almost outweighs the higher redundancy. I'm sure NASA has calculated the trade off, but I'd be curious to see the thoughts behind that.
I feel in a similar vein when learning of certain aircraft accidents over the years, where it feels like the redundancy of certain systems and the complexity it adds has been the indirect cause of accidents instead of preventing them. I suppose there's not really a way to quantify the accidents that it's prevent to be able to compare them directly.
There’s an obvious example of this with twin-engine airplanes. Having two engines obviously makes you a lot safer since you still have power if one fails. But dealing with an engine failure takes some skill, and your probability of experiencing a failure doubles. Airlines train their pilots to handle it, but if you’re a more casual pilot and you’re flying a twin, you have to be careful to ensure it’s actually making you safer.
Another example would be something like a leader/follower distributed data storage system. It (and maybe its clients) needs to maintain a coherent view of which the leader node is. This adds significant complexity, and in many cases is no longer worth it.
Two engines also give you a lot more options for control surface failures. It's objectively safer and why all commercial airliners are (at least) two engine. But it does require more training for the pilot.
The acceptable loss of crew risk for Artemis is 1 in 30 (3.3%), and I gather figures like that feed into the engineering constraints dictating the design (level of redundancy, materials selection, etc).
To be fair, delineating between benevolent and malevolent pen-testing and cybersecurity purposes is practically impossible since the only difference is the user's intentions. I am entirely unsurprised (and would expect) that as models improve the amount to which widely available models will be prohibited from cybersecurity purposes will only increase.
Not to say I see this as the right approach, in theory the two forces would balance each other out as both white hats and black hats would have access to the same technology, but I can understand the hesitancy from Anthropic and others.
Yes, and the previous approach Anthropic took was "allow anything that looks remotely benign". The only thing that would get a refusal would be a downright "write an exploit for me". Which is why I favored Anthropic's models.
It remains to be seen whether Anthropic's models are still usable now.
I know just how much of a clusterfuck their "CBRN filter" is, so I'm dreading the worst.
> since the only difference is the user's intentions
Have these been banned yet: dual-use kitchen items, actual weapons of war for consumer use, dual-use garden chemicals, dual-use household chemicals etc. etc? Has human cybersecurity research stopped? Have malware authors stopped research?
No? then this sounds more like hype than real reasons.
There's also the possibility that there's a singular anthropic individual who's gained a substantial amount of internal power and is driving user-hostile changes in the product under the guise of cybersecurity.
But this technology is now out there, the cat's out of the bag, there's no going back to a world where people can't ask AI to write malware for them.
I'd argue that black hats will find a way to get uncensored models and use them to write malware either way, and that further restricting generally available LLMs for cybersec usage would end up hurting white hats and programmers pentesting their own code way more (which would once again help the black hats, as they would have an advantage at finding unpatched exploits).
Basically every single old bug report I've ever seen is essentially a red-herring that is usually not able to be reproduced anymore after N years and takes away time from focusing on newer and more solvable issues. I don't see the issue with removing that noise if it's no longer being reported, but to each their own I suppose.
Sure. So try to reproduce on a current build, and close with a "No longer reproduceable on ___". That'd be good practice. Closing silently because no one can be bothered to evaluate at all is horrendous, and creates the user expectation that "no one looks at these, so I'm not going to keep reporting it" which "justifies" developers closing old bugs.
I agree with you about that, but why would an ill-defined report be kept open in the first place? It shouldn't be. Give the user an opportunity to provide more detail - for my own use I have some auto-text "scripts" set up, to make prompt questions easy - and then auto-close after a few days.
[Edit, answering my own question: they're left open because they were ignored to begin with.]
I write excellent bug reports, the vast majority of which (I'm thinking of one service-provider in particular, may they live in shame) get ignored. Or escalated and ignored; somehow that feels worse, though I don't know if it should. I guess it's the hope. It's the hope that kills you.
Every other month I get an email from a legacy pre-GH bug tracker that's either a "me too" or "bug fixed in latest release" a decade after I filed these one-offs you would be so quick to throw away. Bugs with no activity for years on end.
the right thing to do is to actually ping the original reporter if possible, or a developer that you might assign the bug to and try to drive it to a conclusion.
if the answer is 'everything in that part of the code has been rewritten' or 'yeah, that was a dup, we fixed that' or 'there isn't enough information here to try to reproduce it even if we wanted to' or 'this a feature request that we would never even consider' or some other similar thing, then sure delete it.
otherwise you're just throwing away useful information.
edit: I think this difference of option is due to a cultural difference between (a) the software should be as correct as reasonably possible and (b) if no one is complaining then there isn't a problem
Closing bugs because of a rewrite is probably the most harmful practice in the whole industry. The accumulated unresolved issues of your existing code base are a rich resource of test cases. Writing the new code base without checking to see if it fixes the old bugs is a mistake.
sure. But you can say put "please verify whether it is still present" via bot before doing so. Which apple did and I'm not sure why blogpost author is complaining about that
> you can say put "please verify whether it is still present" via bot before doing so. Which apple did
No, that's not what Apple did. They said, "Please verify this issue with macOS 26.4 beta 4", a very specific version, implying that they actually fixed the bug in that specific beta version (spoiler: they didn't). And I would have to go out of my way to install that specific beta just to "verify" the bug. Moreover, they gave me only 2 weeks to verify before closing the bug that they hadn't responded to at all in 3 years.
They suddenly created artificial urgency for no apparent reason.
While I fundamentally agree with the basis of compute getting cheaper by the year, I think a missed consideration here is the fact that these models are also requiring exponentially more compute with each iteration to train, in a way that arguably has outscaled the advances in compute.
Whether a generalized and broadly usable model will be able to trained within some N multiple of our current compute availability allowing the price to come down with iterative compute advances is yet to be seen. With the current race to the top in terms of SOTA models and increasingly iteratively smaller improvements on previous generations, I have a feeling the scaling need for compute will outpace the improvements in our hardware architecture, and that's if Moore's law even holds as we start to reach the bounds of physics and not engineering.
However as it stands today, essentially none of these providers are profitable so it's really a question of whether that disconnect will come within their current runway or not and they'll be required to increase their price point to stay alive and/or raise more capital. It's pure conjecture either way.
Circularly passing around tens to hundreds of billions of dollars for things which don't exist and may never exist to fund a technology that hasn't A. lived up to the hype they've marketed and B. proven any strategy to breakeven is fundamentally not that much different than the way in which Enron strategically boasted their revenue numbers by passing the money between shell corporations that their CFO created.
The main difference of course being that these are actual companies as opposed to just entities intently designed to inflate the apparent financials. While it seems like that difference means this situation is perfectly fine as compared with the fraudulent case of Enron, the net effect is still the same; these companies are posting crazy quarter over quarter revenue growth, sending their stock prices to crazy highs and P/E multiples, while the insiders are cashing out to the tunes of hundreds of millions of dollars.
I don't really see how exactly you're trying to make the argument that it may or may not be a bubble, it objectively meets the definition of a bubble in the traditional economic sense (when an asset's market price surges significantly above its intrinsic value, driven by speculative behavior rather than fundamental factors). These companies are massively overvalued on the speculative value of AI, despite AI having not yet shown much economic viability for actual profit (not just revenue).
Worse yet, it's not just one company with inflated numbers, it's pretty much the entire top end of the market. To compare it to the dot com bubble wouldn't be a stretch, it'd basically be apples to apples as far as I see it.
Ditto. If anything, trying to add it into an existing codebase via JSDoc has only really been a detriment via being a massive time sink. It might have caught maybe 4-5 bugs in the code but none that presented a large enough issue to warrant the time investment. If you're starting from scratch with TS instead of JSDoc, it might be worth it, but even on the best of days trying to figure out typing oddities from library typings being wrong and such have only really added headache. As always YMMV
