2. There's a potential to optimize a lot of economic activity in there.

I feel like it's more friendly and chill way to get into computing than what kids get these days -- too many options, leaky abstractions, etc.

And it's not hard to go from BASIC to assembly to understand how computer work on lower level - BASIC commands only do a little bit of computing at a time, so you get used to it. While Python and JS line of code can do a lot...

Or do you think all the wedge issues organically crystallized in voters' minds?..

I've been making GUIs (among other things) for 25 years, including 12 years using React, so you don't need to tell me how amazing it is. There's nothing particularly wrong with using React for rendering (although there's a whole lot of gotchas), the real problem is when people use React hooks for business logic - that's like you decide you need to fetch something in a middle of rendering screen.

Normally KV cache works only if your context prefix is identical, but there are papers which demonstrate documents can be cached between different contexts.

There are papers describing KV cache precomputation for commonly used documents (e.g. KVLink), but, of course, it's not a priority for model providers: they'd rather sell you more tokens, also they would rather get to AGI/ASI first than optimize usage of existing models...

I think a lot of people who might be interested in this product might be interested in an easy set-up process. Even if it doesn't really save time for an experienced ops person, a lot of people would rather talk to a bot than fill a form.

It's generally far easier to install spying software under a computer under your control than to detect it.

So other options exist, it's just that most people (and authors) don't give a flying fuck and give their money to bloodsuckers

Then, perhaps, your local tap water is already close enough to that reference that you might not need to bother.

E.g. with tea I'm wondering if I'm bottlenecked by the quality of tea, water, my technique or taste buds. So I'd buy some expensive reference water at least once just to eliminate one of variables.

Banks make money by giving out loans is a meme, but it's actually true here. You kind of need collateral to do that, but a stock of a company which has revenue is a perfectly cromulent collateral even by strict standards. It's not even some infinite money glitch - it's kinda how the whole system is supposed to work.

The stock market is largely about betting on expectations of future value while money is just a token which is used to settle things. E.g. if you think about simplified mechanics of IPO, say, investor Alice buys OpenAI shares, OpenAI gets the money and Alice has shares. If for simplicity we assume that Alice and OpenAI use same bank and there are no intermediaries, then it literally just updates two cells in a database. And Alice now has shares which is an asset of known value, thus can be borrowed against, etc. Also, say, OpenAI can use that money to repay debt, then perhaps lender would buy SpaceX stocks - it's not like money was withdrawn from the system.

Of course, there can be some interference: multiple companies do IPO around same time it would reduce FOMO, and if they did it literally in one day there might be lack of liquidity.

Usually people point out that humans are more sample efficient: they might notice a novel pattern in a handful of samples, whereas training NN might require take millions.

However a claim that LLMs fundamentally cannot do abductive reasoning at all is not warranted - we don't see a clear cut, it just looks like the way LLMs do it is less efficient.

Flawed business logic might corrupt data, but that's much less rare than security vulns, and might be solved by versioning data (e.g. copy-on-write, even Windows had Volume Shadow Copy service which can take a snapshot of all data).

The main problem is that there's no incentive for software vendors to separate parts: e.g. app which processes financial records might also send/receive data over internet. If user had a more explicit control over flow of data (e.g. imagine n8n style pipeline) many logic flaws like sending data to wrong place could be eliminated.

It's just that we are used to coarse-grained permissions and abstractions defined back in 1970s. E.g. an app gets access to entire network stack and then can do anything - send telemetry, spam, download code, etc. If we had more high-level comms layer on top of app it could be much more inspectable.

A C program which just manipulates strings and other data structures can have a remote code execution vulnerability because C is a shitty language with no memory safety, data and control flow can be mixed, etc.

But that's just not true for high level code, say, in Python. If you don't use some low-level hacks, Python code just cannot corrupt memory, by construction, and it cannot cause RCE. You can execute attacker's code only if you use a language function which might execute code, say, eval or unpickle. But there's only a handful of such constructions and Python developers could easily implement hardening which would forbid any such calls, guaranteeing that only code which was written by developer gets executed.

Yes, occasionally there might be a logic flaw in code which needs to fixed, but it's not same as weekly updates - framework version 1.2.3 uses package 4.5.6 which has a vuln. That's only recent lunacy.

I'm not saying that e.g. everything written in Python in safe - but that old platforms were almost ready for "works forever" software, and we don't have that anymore,.

But on contrary, business incentive is to make "everything app" which needs to be continuously patched.

But modern Java developers don't want to write this way, it's not "modern".

I guess incentives aka "job security" is the main force here. Would you rather say that a piece of software is "done" and can keep working for decades with only periodic maintenance required, or would you rather "we need to migrate from Quux to Baar as Quux is deprecated and unmaintained now, and Bazz might not be optimal from performance standpoint so we need a replacement. so yeah we'll be busy this year"?

And conference people are so helpful with "Baar is the only valid way to make Java now. If you think about rawdogging JCL you're a goblin"

We had a recipe for a much stabler stack decades ago: separate runtime (might need to be patched regularly) from a high-level business logic (never needs to be patched if done properly).

E.g. old way of developing web front-end was like that: you code directly in JS. It never needs to be patched, only browser needs to be patched.

Same thing with Excel/VBA, etc.

But new devs don't know any of that, they just want to use latest "framework" which pre-installs whole bunch of vulns. And if there's a patch you need to rebuild. Constant churn just to satisfy the trend

In the past we had software stacks where once code is written it's just done, it will keep working years and even decades later.

E.g. https://sapaclisp.common-lisp.dev/ you can download code written in 1993 and just load it in latest SBCL.