stkdump

Glad I stocked up on them before the tariffs took effect.

Using more fingers allows for faster typing.

Sounds like they are doing something similar to gain of function research. How can we make LLMs more harmful and then study their behavior?

The modern universal keywords if, else, for and while are good because they are fairly short and thus quick to type.

I guess we are going to learn how important secure communication is based on the stories (or lack of stories) about how it is being exploited in the wild.

I think the point made here is that the application runs as if it were a modern application, even though the OS is completely unrecognizable when compared to the OS it was written for. There are other ways to run old applications on modern hardware with modern OSs, which the author would consider cheating for the purpose of TFA. Heck, I can run ancient DOS and gaming console applications on my phone if I wanted to.

There is this narrative I heard from a Brazilian near me that the Supreme Court in Brazil is political and rotten to the core.

That's not news though. In fact almost no company beyond maybe 10 people that has a large central repository has no other smaller repos with other smaller production projects. They still always call it monorepo, because it approximately still behaves like one.

Now if he could just focus on such stuff and stop undermining democracy and working with fascists, he would be quite a cool guy.

Could the dentist just stop working and continue to make that part of their income?

Why would you want to override system binaries

Looks dangerous to put a user writable directory ahead of system directories in PATH

I must say, I had this thought. While everyone thought AI written code will inevitably lead to slop, bugs and security issues, I had the feeling the exact opposite happens. I can task an AI agent with striving for the quality metrics I want to see, and it will always work along them. No fatigue that leads to errors, almost no oversights even in more complex systems, etc.

This may actually be the time where it becomes feasible to create high quality software with reasonable (human) effort.

What we are seeing with AI generated incident reports causing issues is maybe mostly an impedance mismatch between people who have fully adopted AI and people /projects who haven't.

Right. The EU still seems successful in shaping (foreign) tech to some extent. Handing out huge fines is maybe less important than effecting change. Though it would of course be good if other national/transnational regulators would join in and take care of some of these topics. Imagine for example if Japan, South Korea, Taiwan, Australia and New Zealand teamed up. Together they might be able to accomplish something.

There is a lot of innovation happening in Europe, it is just that Europe is better in small and medium businesses than startups that become unicorns and tech giants. Interestingly that has always been the case, so it isn't even a recent development. For example while Ford is known to have invented the assembly line, in Germany it is the car supply industry that always came up with innovations and the car manufacturers then just put the components together to make full cars (sure, this is a simplified view). So there are some large companies, some of which are known and very successful worldwide, but they are not usually thought of as innovators. Large companies in Europe don't take real risks, so it falls on small companies that do that with limited funding. It's just a shape of the economy that Americans have a hard time to wrap their heads around.

It takes EU regulators like half a decade or so to make up their minds on each issue.

Not sure if I buy special LEDs, but I have outfit my house with LEDs basically everywhere between 10 and 13 years ago. In that time I had maybe one or two of them die.

Traditional light bulbs have taught us that lights naturally have to be "consumables". That has been far less true for energy saving lamps (of which I have maybe 2 or 3 still left which I planned to replace by LEDs once they die, but they just won't). As far as I can tell, this isn't at all the case for LEDs.

It's much more likely that lamps and ceiling fans made out of plastic break from accidental physical impact or turn ugly due to natural UV discolorization or similar. And probably most will live on until replaced due to changing tastes.

I don't know. It would surprise me. For long agentic work you shouldn't need that many streams for the KV cache to become larger than the (active) parameters. At 128 streams the model weights would be neglectable. I am using a 22GB model file, i.e. I have 10GB for context, which isn't even the max that the model supports.

But there is also a chance that you get insanely rich and the world isn't destoyed! It's the entire logic of SV and VC.

I have a computer with a 5090 on a smart plug at home running Qwen3.8 27B for agentic coding. On a busy day it can use around 5kWh, though on most days it is around 2kWh. I am sure cloud is more efficient because there is probably efficiency in running many parallel streams, some of the models have fever than 27B active parameters and the power draw of the non-GPU components is also spread over more GPUs. But still I also believe that the energy use numbers you get from the inference providers are a bit "beautified". After all, they still fight a political battle and have to show that it isn't all so bad.

Having said that, seeing the incredible progress of models throughout this year, I also strongly believe that the planned buildout is overeager. Even I with my gaming hardware often run out of instructions to give. And the smarter the models get that I can run, the less I will be able to saturate my hardware. Is it because of my lack of creativity of which kinds of tasks I can give to AI? Maybe a bit, but currently I can't believe that I am that far away.

If you look at the patch, it is just disabling a (presumably new and buggy) feature.

I think you missed the little word "relevant" on top. I am of course aware that there are exceptions. And yes, if you write C++ for embedded or other minor or outdated platforms you will know and understand that these things don't apply to you. But there are tons of developers around writing code that will never touch any of these specialized systems that spend way too much effort trying to be clever, because of "the standard", and "that platform over there".

The problem begins when you start mixing the traditional types and (u)intN_t, because the latter are merely aliases for the internal types, and it messes up overload resolution. All relevant platforms have pretty much agreed the size of char, short (int), int and long long (int). They have different opinions about long (int) and thus an int64_t might use either long (int) or long long (int).

So the best solution for nowadays is to use just char, short, int and long long (and make strong assumptions that these are exactly 8, 16, 32 and 64 bits wide respectively), never use long or long double. Never use (u)intNN_t. Then you are good.

Those caveats of the past (but int might be 16 or 36 bits), are exactly that. An artifact of the past. A historical curiosity. Not relevant for today or the future. No, I don't believe for a second that any future platform will change their size.

Platforms also still disagree on the signedness of char, so when an 8 bit numeric type (as opposed to an ascii character type) is needed, one should always explicitly specify signed char or unsigned char, both of which are separate types from char.

Further things of note: platforms also have agreed on little endian (so called "network byte order" is dead and should never be used in new protocols, because it forces everyone to convert) and on IEEE memory representation of float and double. Contrary to popular belief the main floating point operations (+,-,*,/,==,<,>,<=,>=) are also precisely defined and always behave exactly the same (leaving out strange edge cases such as denormals). And yes, of course platforms have very long agreed on twos-complement for negative integers. This even made it into the standard at some point, I believe. Same happened with the memory layout of a vector<>, which in the past wasn't standardized, but because everyone of course did the obvious (and made it the same as a normal C array), it was added to the standard later.

What I am saying, what the C++ standard guarantees isn't everything. There are much more guarantees modern C++ code can (and should) rely on.

10% smaller is 3*0.1=0.3 smaller than 3, which is 3-0.3=2.7

So 200% smaller is 3*2=6 smaller than 3, which is 3-6=-3

Which is why these kinds of statements usually don't make any sense at all. Usually something can't be more than 100% smaller, at which point it is completely gone.

Also, X is 9 times larger than Y and X is 9 times as large as Y are two different statements.

They also said that theur hardware scales faster than Moore's law, when in reality it is way slower than Moore's law. Which I guess at least is a good thing for hyperscalars because it helps with their decision to write off their GPUs over a much longer period.

But still, it seems that billionaires are lying left and right. It isn't just Elon.

An autonomous car in front of me can still act in a way that I or my car can't predict, as long as we haven't eliminated humans and animals completely from being anywhere near roads.

Seems I got terms confused. Thanks for clearing that up.

A line of constant bearing will always be a great circle. A straight line on a mercator projection of the earth does not constitute a great circle (in fact only the equator line is a great circle and each vertical line is half of a great circle).

Once a hash table has outgrown all caches, it should have linear performance. It's just that caches accelerate it at sufficiently small sizes.