Genuine question - it means you are not spending that long time touching the code at all if it only gives a 10% improvement. So what is the rest of the time spent on? Where I work devs complained about too many meetings - scrum, refinement, standup, PM meetings, meetings with UX etc. but overall the meetings were at most 10-25% of their time (depending on the person) the rest was really working on the code.

This seems like a flawed way to look at it (considering exploitability of the found Mythos bugs). Feels like there's a bit of Y2K to it. Mythos was used in project Glasswing to allow many of these bugs to be found and fixes before the models were out - all this happened in spring when no one had access. Microsoft has now had two completely outsized patch tuesdays (the last one was 500 security fixes or similar) and I also recall a Firefox graph of fixed vulns that were completely through the roof compared to any previous point in history. So a lot was fixed before anyone got access. Finally, when the public did get access it was to a model with a lot of safeguards (often falling back to Opus) and not even available for a long period of time before this was strengthened even further.
Also even if we accept the premise from the article that the new-found bugs have the same percentage-wise chance of being exploitable, that still means the enormous increase in AI found bugs will lead to a proportional increase in exploitable bugs. But as I wrote the recent they may be less exploitable is simply that they are already fixed.
But wouldn't some of those bugs still slip through especially considering orgs being slow to patch - if we look in the real world there is a considerable rise in data breaches which is attributed to AI: https://readthereporter.com/me...

Palladium (later renamed NGSCB) was earlier, with the peak around 2002-3, before being scrubbed. Sandy bridge was 2011.

Not only that - when they scrapped 20A in August 2024 and delivered arrow lake on a TSMC process, they said it was because 18A was going so well so they wanted to focus on that: https://newsroom.intel.com/opi... "One of the benefits of our early success on Intel 18A is that it enables us to shift engineering resources from Intel 20A earlier than expected as we near completion of our five-nodes-in-four-years plan. With this decision, the Arrow Lake processor family will be built primarily using external partners and packaged by Intel Foundry."

Guess it was harder for a hacking culture to appear without internet, and things were less standardized, so it would be a tough job for a lone hacker to do it - but of course "Woz"-level hackers would have been able to. Besides, the first teletext implementations were done without a single microcontroller /MCU. Just a bunch of fixed-function IC's chained together. One for extraction the teletext stream, a shift register for latching in the 3-digit page number, a chip that could filter out a particular page matching that number and copy to RAM, the character ROM etc. Even the features like hold, reveal-hidden etc. were just input signals that made minor modifications to what these chips did.

Cancer persistence is more complicated - the tumor may produce molecules that inhibit the immune response of that prevent presentation of the tumor antigens to the immune system. Also not all genetic sites are presented (and thus available for inspection) even under normal circumstances (depending on the HLA/MHC genes which are highly individual). In general it is much harder for the immune system to recognize - after all, it is the body's own cells, just with some mutations. In contrast with e.g. a bacteria that is a whole different organism, or a virus that installs completely new genes and produces new proteins. But the immune system definitely does play a role in recognizing and eliminating cancer, but clearly it is imperfect.

It is probably controlled as by the same general regulation mechanisms that ensures self-tolerance. There's central tolerance ensuring that immune cells that attack the self are killed. For T-cells in happens in the thymus (thymus education, if you want to look it up) where it is tested if the newly produced T-cells react to any self material. There's also other checks and balances such as T-cell getting killed if they react too quickly after having been released from the thymus (suggesting it is more likely reacting to something in your own body than an incoming disease agent). It is plausible these mechanisms also ensure self-tolerance against these cells from the mother.

I stand by every word but it is hard to refute a message like yours with no content at all. What were you thinking writing this

Look at the post I am responding to claiming they don't see how it is even possible the c++ version could be slower! I am giving reasons why it could be which is enough to refute that statement. About this being a different implementation: sure but if it wasn't there would be no point in discussing this at all. I was thinking of the question of "reasons why programs written in C+( using its language features could be slower than something written in C" from a practical perspective of how such implementations might be. If it is the same code in both cases yeah of course c++ is not slower

A C++ implementation would often try to use C++ classes and perhaps features like operator overloading to have nice syntax. This can easily lead to code passing objects around and involving deep-copies of such objects. The alternative would be to pass pointers to the classes around but then you lose some of the benefits of objects cleaning themselves up as they go out of scope. In C the programmer might be naturally more inclined to pass around pointers around to begin with, because there's no destructors anyway and less focus on RAII. Later iterations of C++ with move semantics in combination with various auto pointers make it possible to avoid a lot of that copying while retaining the benefits, but that is only a relative recent addition and not all C++ developers are familiar with these features.

TL;DR: AI's huge initial productivity gains can create a false sense of competence that leaves you stranded when you hit problems beyond its reach. I consider myself an experienced developer and AI user. I recently got a task of getting an old commercial software product to work. It had not been maintained, not compatible with new o/s and packages, and the huge installation guide with tons of manual steps was probably never fully correct etc. I also didn't know many of the underlying packages and application servers well, which normally wouldn't matter for this kind of 3rd party product - until it did. Anyway, I decided the right approach would be to sanitize it all and to dockerize it, and since I haven't worked much with Docker I turned to AI help. It quickly found answers and solutions to lots of things that came along. I could basically give it the whole installation guide and have it dockerize many steps first shot. It even helped with some of the 'application level' problems that started to emerge and I became more and more ambitious in what I could let the AI do. Huge success.

This was until I reached a problem concerning one of the embedded application servers, that none of the AI's could crack. I tried everything - new context windows, new AI's, providing all conceivably useful context info (stack traces, even decompiled files etc.) and symptoms based on my own hunches and debugging skills - but nothing helped. I also let the AI suggest what further info could be needed. But nothing helped. This problem was completely out of reach for the AI's - even with my debugging help. And this was the worst - because I had let the AI do so much stuff and not researched it myself, I kept trying to get the AI to fix it and so wasted a lot of time because it ultimately couldn't. Also, I was no longer in a position to debug it myself. I basically didn't fully know what I was doing, I was missing steps on the knowledge ladder. Eventually I had to throw in the towel and basically retrace everything the AI had done, why it was done that way, how/why it worked, and properly research everything and THEN deep-debug it.

This is not a criticism of AI's as such, it is unreasonable to expect a quick fix to everything. But it is just to show how some of the initial time savings (that were indeed huge) can be eaten away when the quick fixes stop working.

I looked it up - most researchers would probably pick 29 years as the current age of the youngest millenials!

Millenials is a very brought term but the youngest millenials are now 25 and the oldest 45. I'm at the far end of that range, and here tattoos weren't very common. Of course some people would have it but it wasn't that many and it was often in somewhat discrete locations e.g. upper arms etc. so it was hidden with clothes on. It seems to me it is the younger generation, those who are actually young now who have really picked up on it, often with extensive tattoos on the entire forearm and this being an entirely mainstream thing. It seemed to start maybe 5-6 years ago so I guess some of the last millenials were part of it too, but it doesn't seem to be a millenial thing - more a gen-z thing.

The rewrite happens automatically in the background while the disk is idle - while proprietary I would guess all recent SSD's (at least TLC/QLC) does this. But note that it has not always been so - for instance, for the 840 EVO this was added in a firmware update, when retention starting to become a problem (it was one of the early TLC disks so likely it had not been much of an issue before). What is not known is how long to keep the disk on... when will the disk start the process, how long does it take, can it resume if interrupted etc. I've seen papers investigation the algorithms by looking at the power consumption of disks while idle, thereby making inferences about what is going on. But it is fully proprietary and as the 840 EVO shows it can vary for the same model based on firmware.

The mechanisms are proprietary but generally it works as a background refresh mechanism. So probably mostly when idle but even though it likely won't do it continously as that would wear it out and even just scanning would cause constant high power usage. It would be nice to be able to monitor when a refresh starts, how far it is, resume etc.