zigzag312

> VW AG is partially state-owned, with a double-digit percentage held by the federal state of Lower Saxony.

Yes, but those are two separate things. Lower Saxony owning part of VW doesn’t mean VW gets extra public money because of it.

High subsidy rates alter market dynamics. Can we agree on that?

Yes, but not nearly to the same extent.

First, the subsidies to consumers for electric vehicles in Germany apply to all cars, not just those built in Europe. This effectively subsidizes the competition from China.

For subsidies to manufacturer, as I didn't quickly find any source making the direct comparison, I asked LLM to research it (I apologize for for this, but doing it manually would take too much time).

   BYD: ~15% producer-focused economic benefit under the Commission's methodology; 17.0% including the legacy NEV fiscal scheme.

   VW Europe: ~0.2–0.7% is my best public-data-based estimate of currently observable and allocatable producer support; roughly 0.7–1.3% if we deliberately make aggressive assumptions favorable to VW.

   VW extreme stress test: ~2.5–3.2%, obtained by implausibly allocating essentially all VW Group grants and tax credits to European BEVs.

EU Commission's investigation calculated countervailable subsidy rates for Chinese BEVs: see "3.10.3. Calculation of subsidy rates" for a aggregate subsidy rates.

https://eur-lex.europa.eu/legal-content/EN/TXT/?qid=17382497...

By being subsidised by the government.

Agent that has its own computer, plugins to connect it to various services and probably it's own memory. A virtual personal assistant. You could have different specialized Dots each with its own plugins, memory and instructions.

That's how I understand it.

Cloud compute means its work VM is isolated from your devices, so it can't destroy your local data as easily (unless it has access to your devices) and it's on 24/7. A big negative is that you are giving access to even more of your services and data to a third party and the lock-in into a walled garden happens once you start depending on it.

Publish new features first to clients that provide feedback, so rollout can be stopped, if there's an issue with new version. Telemetry off effectively prioritizes stability over speed of recieving new versions.

Yeah me too. Maybe that place will occupy the Astra Minor model that appeared in Microsoft's Azure model config. As Sol and Sonnet are now similarly priced (unless Sonnet 5.5 will reduce its price).

Because it's not under GDPR, but under ePrivacy.

See section 3.6:

https://ec.europa.eu/justice/article-29/documentation/opinio...

The guidelines you linked state: "These Guidelines do not address the circumstances under which a processing operation may fall within the exemptions from the consent requirement provided for by the ePD".

Let's check what "Opinion 04/2012 on Cookie Consent Exemption" [0] says under section 3.6:

"""

3.6 UI customization cookies

User interface customization cookies are used to store a user’s preference regarding a service across web pages and not linked to other persistent identifiers such as a username. They are only set if the user has explicitly requested the service to remember a certain piece of information, for example, by clicking on a button or ticking a box.

...

These customization functionalities are thus explicitly enabled by the user of an information society service (e.g. by clicking on button or ticking a box) although in the absence of additional information the intention of the user could not be interpreted as a preference to remember that choice for longer than a browser session (or no more than a few additional hours). As such only session (or short term) cookies storing such information are exempted under CRITERION B. The addition of additional information in a prominent location (e.g. “uses cookies” written next to the flag) would constitute sufficient information for valid consent to remember the user’s preference for a longer duration, negating the requirement to apply an exemption in this case.

"""

See that you need to provide provide "information in a prominent location (e.g. “uses cookies” written next to the flag)" to be able to store user preferences in persistent cookies. You don't need consent banner for that (which I didn't say you need), but you need to clearly inform the user. The act of setting a preference together with clear information about persistence counts as a valid consent.

[0] https://ec.europa.eu/justice/article-29/documentation/opinio...

The policy is both, good, but also flawed. For example, you cannot persist settings, because one policy says that website settings should be ephemeral unless user agrees to persist them.

Scrolling is like an Achilles' heel of Flutter. There's still no smooth scrolling with mouse for web.

Even if the purchasing entity is backed by a foreign country?

But many of the listed hypotheticals are not dependent (on top) on others, and since there are multiple that actually increases probability of an undesirable outcome.

Yes these can be used as alternatives sometimes, but they are not really the same thing. We need a streamlined way for reusable libraries (written in different languages) to be consumed by different languages while not being limited to a specific runtime or platform. When code from different languages needs to be able to run inside the same process, with low calling overhead and avoiding copying when possible.

Your answer just throws in anything that enables programs to communicate somehow, ignoring all the differences and tradeoffs to what is being discussed here. Many of your solutions lock you in to a specific platform, a language or add a non-trivial overhead like message serialization or add an unnecessary complexity to a program. Also, IR does not solve the same problem as ABI.

Exactly! It's surprising to me how little development is happening in this area.

What about a better ABI abstraction?

Can you share source of this data? I have my doubts about the quality of the data, since OAuth2 is such a complex system with so many footguns.

In the end there is always some long lived secret. What changes is just where and how it is stored, secured and used.

I bet we can generalize to say that data shows that you will likely fail to properly secure any secret (including the ones used in OAuth2).

EDIT: An example: https://news.ycombinator.com/item?id=37973937

I agree with what you said. I just wanted to add that intelligent models probably need to have some notion embedded (but not everything), as some information retrieval is not trivial. Too few embedded notions will hurt it's ability to solve problems but from some point onward you'll get diminishing returns (where it starts to make sense to rely just on information retrieval).

For example, you if you instruct a model to create decoder for some data type users will upload to your website. The intelligent model without notions will retrieve information about that data type and build a working decoder, but it might miss from context that users uploading to a website means untrusted input and thus won't even try to gather information about what it needs to be done to securely handle such uploaded data.

Or if you give it a task to translate text to a language it didn't encounter during training. You can provide it with grammar rules and a dictionary for information retrieval, but I guess it won't perform as well as inteligent model that already has some fundamental notions of that language and only needs a dictionary to expand its vocabulary.

Gpt-4.1 only knows a lot of patterns, but doesn't have reasoning intelligence that would help it properly use that knowledge. So, a small reasoning model can easily beat it in a lot of tasks. The question is how will, 14 months from now, new small reasoning models compare to current big reasoning models.

How much information needs to be embedded is not yet clear, but currently, bigger reasoning models are still better at complex tasks than small reasoning models. Either sweet spot of embedded notions is higher that what current small models have or information retrieval ability needs to improve.

Understanding of a specific problem space can be a prerequisite to be able to form a proper query (i.e. to ask the correct question).

Model doesn't know what it doesn't know.

Ah, now I see what you meant.

Of course you can have reactive state, your complaint however was:

"The react in react stands for reactivity, however it is not." [because] "Its entire state management is not reactive"

React is primarily an UI library, not full state management library. And its UI is reactive.

UI is reactive, not state. You push changes to state and UI reacts to it.

> It roughly compares with GPT-4.1 (!!), released 14 months ago

I think the mayor win for coding was reasoning. That's why such a small model can match GPT-4.1 in coding, but I suspect that GPT-4.1 still wins in general world knowledge due to bigger size.

It's not arguing that predictive power is bad. Just that people often mistakenly believe some phenomenon is understood more deeply than it really is, because a model can fit data and generate accurate predictions.

> The out-of-the-box Shotwell manages photos quite well without any intelligence.

This piqued my interest on how it does it and after briefly checking the project it seems it only has two features for automatic photo categorization. 1) it can group photos by date and 2) It has face detection and recognition that uses trained weights (so ML "intelligence").

One interesting thing about Barman is that it just uses PG's own backup utilities. It doesn't implement custom parsers and things like that. So, there's less maintenance work needed for Barman when PostgreSQL changes data-file internals. Tradeoff is that there's less custom optimization than pgBackRest/pg_probackup/WAL-G-local.

Databasus seems to be taking somewhat similar approach to Barman, but (at this time) does not appear to use pg_receivewal, which makes it less efficient than Barman.

For PG v17+, Barman seems to be the most efficient backup solution based on PG native tools, that is able to do low-RPO or even zero-RPO (if configured as a synchronous receiver).

pg_probackup seems to be another one.

This project looks nice, albeit a bit young for a backup tool.

Did you encounter any issues or limitations?

Is that info up-to-date? Their readme states:

  **Backup types**
  
  - **Logical** — Native dump of the database in its engine-specific binary format. Compressed and streamed directly to storage with no intermediate files
  - **Physical** — File-level copy of the entire database cluster. Faster backup and restore for large datasets compared to logical dumps
  - **Incremental** — Physical base backup combined with continuous WAL segment archiving. **Enables Point-in-time recovery (PITR)** — restore to any second between backups. Designed for disaster recovery and near-zero data loss requirements

EDIT: It seem PITR has been added this March (for PostgreSQL)

https://github.com/databasus/databasus/issues/411

Handling of exceptions is not enforced at compile time, while ownership is.

Better example might be statically typed languages. They were harder to use at first, but now with good type inference and features like generics, they are much more ergonomic than at first. The accessibility gap between static and dynamic languages has narrowed with time and maybe we can expect that user-friendliness of ownership will also improve like that.

Reference counting is a form of garbage collection.