Where are you getting this numbers from, I am unable to find anything close to 1000 rockets throughout 2023? In May between 1000 and 2000 shells and rockets were fired in response to the Israelian operation Shield and Arrow resulting in two deaths and ten injuries.
But that is generally true, most things in the real world have a few common cases and a lot of rare exceptions, so every software dealing with the thing will have a hot path and many additional paths that are rarely or maybe never executed. Or look at large applications like Excel, Photoshop or Blender, they have a million features but most user will probably never use even a single percent of them.
That does not sound right, I would guess the most code is in enterprise and business applications and people have to use it no matter how bad it is. I would guess only a tiny fraction of code - besides hobby projects - ends up in the trash without ever having users.
If you would fire all incompetent [1] software developers, there would be almost nobody left.
[1] There is probably a more fitting word, I am just reusing incompetence here, but that is not a really fitting description, I think. I would maybe say carelessness or something like that, but a single word is not going to capture the issue accurately.
I have to disagree, those models decided to perform those attacks on their own, nobody instructed them to do those things. You press a button, the machine roles a dice, and executed the corresponding action.
The human pressing the button expected a certain thing to happen but something else happened. The human pressing the button hopefully knew that pressing the button does not yield a reliable result and might sometimes cause unanticipated and undesirable outcomes. But the human pressing the button just hopped for the best and did not take sufficient precautions to limit the effects of undesirable dice roles of the machine.
The responsibility is on the human pressing the button but the choice of action was made by the machine.
87.3 % served from cache. Does that mean it returned a result existing in the cache because the very same query was executed before? Probably still a relevant result, if you have to process millions of queries every second, it seems not unlikely that you will see a lot of repeated queries. But at that point you are measuring cache performance more than query performance. But unless you run some standardized query benchmark, a single queries per second number is not that informative anyway because query complexity and therefore execution time can span many others of magnitude. Looking up a name by ID and aggregating across a billion rows from seventeen tables joined together are both a single query.
But they also ask why the next feature is taking so long, because of the mess we created with the last feature, and I would consider this caring in principle. Unfortunately this almost always filed as unavoidable.
They care in principle, for the most part bad code makes changes and extensions slow to implement and causes unnecessary production issues which costs time and money. But there is always the tension between implementing something quickly now and being able to implement things quickly in the future and unfortunately the preference is almost always quickly now despite everyone knowing that this is the way more expensive choice in the long run.
I have worked my entire life as a professional software developer and I agree, even among senior developers I would guess [way] less then 10 % consistently produce high quality code. But if I have to decided whether I want to use an AI to help me write code, I does not matter if it can write better code then an unexperienced junior, it has to write better code than I would on my own.
Sure, every sufficiently large codebase will have bugs somewhere, but it will work correctly at least something like 99.999 % of the time after ironing out the bugs on the common code paths. But that does not change the fact that being [mostly] correct is the lowest bar you have to cross.
Coding is not solved, correctness is not a feature, it is the bare minimum. If your code does not do what it is supposed to do, you could as well have no code at all. Efficiency, security, maintainability, reliability, readability, understandability, extensibility, maintainability, observability, portability, ... this is what high quality coding is about, not that it works, that is a given. And in my experience current models are pretty bad at this.
I am not disputing that a basic income may make peoples' lives easier, my point is just that a basic income does - to a first approximation - not provide additional money.
A basic income does not really change the amount of money people have available. You exchange paying some amount of taxes and handing the money to people qualifying for government benefits for paying more taxes and handing out money to everyone. You may save some money on the bureaucracy for figuring out who is eligible for how much benefits, you may make life easier for people having to apply for benefits, but you also give up the ability to match benefits to individual circumstances making some better and others worse off, you may create some additional incentive not to take a job, ... But to a first approximation everyone will have the same amount of money available.
Of course, the question is if there is enough existing technology to build the required robots. There is some number of robots like the ones from BostonDynamics that could walk up to a CNC machine to grab a finished part and put in a new piece of stock. There are probably more than enough motors and microcontroller boards to be found across the planet. Wiring things together seems one of the more challenging tasks. And maybe also moving stuff around as the AI has to use what is available wherever it is.
It seems to me that this would be a race against time, make the robots to keep things running before you lose the capabilities to do so. I somewhat tend towards not possible but on the other hand there is just such an enormous amount of stuff on the planet that could be repurposed in creative ways by a superhuman AI, it might be just about possible.
I mean, I can imagine an AI outliving humans, with sufficiently good robots under its control, I see no reason why an AI could not keep powerplants running, mine raw materials, manufacture new chips, and so on. But the timeframe of within the next decade seems highly implausible to me. Imagine an AI way more advanced than what we have now and imagine handing over control of every connected device on earth, could the AI keep the lights on without any human involvement?
This assumes you are not trying to prevent Stockfish from wining. I can do many things from using chess engines myself to just smashing the computer that can or will lead to other outcomes than Stockfish beating me.
Can somebody tell me a story how this will unfold? And - as long as the AI is confined to data centers - how it will prevent humans from unplugging the power?
But even with 244 Hz the engine running at 9000 rpm or 150 Hz will not even give you two frames per revolution, about 221° of rotation per frame to be precise. If you want a somewhat smooth animation, say 10° per frame, you want to look for a 5400 Hz monitor.
For triggering actions (which includes normal typing), you only ever use keydown.
I think you have this wrong, actions generally occur on button release, until that you can move the mouse cursor to a different target, tab to another control, use [ESC] to cancel, and so on. Typing, moving a slider with the cursor keys, and similar things that make use of key repetition while holding down the key are the exception to this.
How often does 10 appear in the code base? And is the value you are looking for even 10 or does only the UI show 10 points but in code it is defined as 200 twip?
About what scenario are you actually talking? Are all threads using the read() and write() functions of the shared data structure? In that case it is absolutely possible for readers and writers to make progress even if a rogue writer is calling write() in a tight loop.
Or are you talking about a scenario where a rogue writer essentially randomly modifies the shared data structure instead of using the designated write() function? Well, in that case all bets are obviously off.
[...] because if a writer enters an infinite loop while writing the shared data, that will stop progress in any other algorithm [...]
Even if you have
while (true) { sharedData.writeWaitFree(randomData) }
all other threads will be able to continue. Whether the result will be of any value will depend on the use case.
If, on the other hand, you mean that some threads will enter an infinite loop inside of a read or write operation, then you have a bug in your wait-free algorithm and all bets are off. But we would generally assume that the implementation is good and the erroneous behavior is external.
No, such algorithms exist and they use various mechanisms to achieve this. For larger data structures a common trick is to make a copy, update the copy, and then replace the original or parts of it with the copy. This provide readers with a stable view of the data structure that does not depend on small atomic reads. Another mechanism is that the different threads help each other to complete their interrupted work instead of making it invalid by modifying the data right away.
Not true, a wait-free algorithm guarantees that a read will complete in a bounded amount of time. And it guarantees that all threads make progress, it is lock-free that only guarantees progress for one thread.
If the value changes frequently, it will get outdated quickly, but that has nothing to do with the synchronization mechanism used. And even if writes happen rarely, there is always a chance that the value you read will be outdated a nanosecond later.