mattalex

SAP has largely switched over to their own HANA database for new deployments. Even before that their "AnyDB" database worked with pretty much any backend and is still supported. The reason you see oracle has less to do with what SAP wants and more to do with "It's what the company/engineers have already used/set up in the past".

Regarding Java, SAP has long switched over to openjdk (though oracle java is supported in some cases). Specifically, they have their own custom fork of openjdk "SapMachine" precisely to be independent from oracle (FYI: if you look at openjdk upstream you will see many core contributors are employed by SAP)

In general, I would say that the actual tech companies that have to interact with oracle's stuff are generally very well equipped to drop them or have already done so. The bigger issue are legacy "consumers" of oracle (e.g. if Pepsi has their data in oracle DB), which often do not have such contingencies.

I wouldn't even say that VW is a failing company: They sold the largest number of EVs in the EU in 2025 (https://autovista24.autovistagroup.com/news/which-brand-domi...) and that is before you consider that e.g. Audi, Cupra and Skoda are _also_ VW brands (and some of the ford cars are built on top of VW's EV platform).

The main problem they have is that you just need a fraction of the number of people to build an electric car than what you need for a combustion car. You no longer need complex transmission, exhaust filtering, turbos, highly complex combustion engines,... all of which are marvels of engineering but no longer necessary for EVs. VW "main" (i.e. excluding sub-brands like audi) was already rather highly staffed (though part of this is due to them taking over some duties for their sub-brands), so the employee impact is higher than what you would expect, but even for a reasonably staffed car company this would imply huge layoffs and changes in the structure of the company.

Why do you assume that the entire EU has brain damage and did not think of this _most obvious_ loophole? Sure the companies could commit crimes but if that is enough of a reason not to pass laws then we better start striking murder of the books as well.

The EU cannot control every avenue you might be sneaking products out for destruction. The goal is not to prevent all sort of destruction, just make it risky enough not to be worth it: Since it's illegal to do, you now have something to fear when you try to get away with your (now) crime.

ESPR regulates the entire placement of products, not only the destruction, e.g. the Digital Product Passport (DPP) which every product has to have (it's slowly being phased in over the coming decade) gives information about repairability, resource used, recyclability,... To do the exporting for destruction you would need to fake the entire paper trail of the product, committing countless numbers of document forgery.

In general the "you are not allowed to destroy unsold goods" part is arguably the small element of ESPR. ESPR also contains the right-to-repair legislation, where ESPR introduces requirements (or at the very least disclosure requirements) for - Design for durability - Availability of spare parts - Access to repair information - Software support obligations - Design for repairability / Restricting design practices intended to hinder repair

The "don't destroy working items" is just a one component of this. The more important component is the DPP which makes the product lifetime traceable.

150M at 5B revenue is not great: that's 3% margin!

The bigger issue is that console manufacturer revenue is highly cyclical. This is hard to see in e.g. Xbox and Sony since they are both part of a larger conglomerate, but really obvious for nintendo.

You generally have a cycle of - "Launch": high marketing costs, low/negative HW margins - "Mid-cycle": lowering manufacturing costs, large game sales, high margin DLCs - "end-of-cycle": falling HW sales, fewer exclusives (-> preparation for next gen), fewer consumers (-> waiting for next gen). Here you usually have maximum profits since you don't subsidize HW and marketing is minimal (platforms are already locked in)

Generally you have to establish a big userbase during the mid-cycle such that you can levarage it during the late-cycle to be able to afford next-gen. Xbox has the big issue that their mid-cycle was catastrophic, which means they now don't have the console base to get into the next generation: If they have 3% margin _right now_ in the end-of-cycle where marketing and development costs are at their lowest, this does not bode well for the overall health of the business.

You can get rid of 99.9% of those attacks by simply dispatching the data consumption to a different instance of the LLM, see, for instance, some of the later patterns in https://arxiv.org/abs/2506.08837

The issue with having a "no answer" option is that you implicitly add a decision problem into your test that depends on the "cost" of answering wrong.

Specifically, your model now has two "correct" classes p(class=y|x) and p(class=⊥|x). This makes the results ambiguous. The way you resolve this is by adding in a cost of missclassification and a cost of answering wrong.

L(y, y') =

0 if y=y' l_err if y≠y' and y'≠⊥ l_⊥ if y' = ⊥

You can then estimate the expected error over your dataset. Notice that this now gives you additional degrees of freedom: Depending on how expensive answering wrong is compared to not answering at all, your predictor might be really bad or really good.

This means when benchmarking with a "no answer" action, you are often not actually benchmarking whether the model works well or not, but rather are benchmarking how well the model _happens_ to agree with the class-error weight you (implicitly) chose in your model.

Because the size of the attention matrix depends on the number of tokens (this is what makes attention N^2). If you don't care about having a flexible number of input tokens (e.g. in image processing) you can learn a fixed routing matrix. This is known as an MLP mixer https://arxiv.org/pdf/2105.01601 : you have one layer that processes each token in isolation ("vertical MLP") but ignores the inter-token connections, followed by a layer that combines between tokens ("horizontal MLP") that treats the internals of every token identically.

Nothing is stopping them, it's just not worth it: Have a look at e.g. vast.ai's pricing (https://vast.ai/pricing).

The V100 (2017 -> 9 years old) can be rented from $0.02 to $0.37/h (right now I can find a V100 with a Xeon Gold 6140 and 48GB RAM for $0.165/h). Let's assume the guy you rent it to pins it at its 250W TDP and let's ignore the running costs of CPU/RAM/etc... Then you draw 1/4 kwh for that compute hour. The industrial electricity prices in the US vary between 7.5 and 25 ct per kwh (depending on state, time of day, etc...), so at 100% efficiency, assuming nothing ever breaks, and the CPU consumes 0W you earn about 14ct/h.

And remember: V100s hours are sometimes sold at 1/10th the price.

If I pick average conditions you need to start thinking of whether it is worth it to rent them out: Usually it isn't unless you have them anyways and just sell idle capacity.

It's barely worth it to run them in a pure "is it profitable" sense, if we also account for the opportunity cost of taking up a slot in your datacenter it seizes to be worth it really quickly.

Regarding specifically depth anything: You're not running this on a microcontroller. In general, CNNs still reign supreme on microcontrollers since you have a way lower peak memory demand which is what usually kills you. Here in this case you have a couple of _kilobytes_ of SRAM, potentially extendable to a couple of megabytes of PSRAM.

Even for small CNNs you often need to do some quite complex interleaving of layers (i.e. running parts of layer 1 and layer 2 in parallel interleaved to take advantage of the downsampling of CNNs) to keep performance and memory impact reasonable (see e.g. https://openreview.net/pdf?id=2O8qbyxH6X).

Think more "image classifier" less "run an image to image transformer". For depth anything, a single layer's activation is probably significantly larger than the available SRAM (I think it is (224/16)^2 patches each with activations [48, 96, 192, 384] for depth anything small: You aren't running this.)

Then allow resale through the platform at the original purchase price.

You still have no scalping, but you recover the ability to back out due to unforeseen events

It works the same way: softmax is essentially just applying the normalization to the vector exp(x). From an "engineering" POV this effectively ensures that the vector you normalize has strictly positive entries, so the result ends up being a proper distribution.

From a theory POV you get softmax like distributions (Gibbs distributions) by trying to balance following some energy E(x) and the entropy of the distribution. In essence the softmax is the answer to "I try to follow the maximum of a function E(x) but I need to maintain some level of uncertainy".

The balancing coefficient between entropy and picking the maximum of the function is called "temperature" (following the behavior of particles in a physical system: The colder the system, the lower the chance of having particles randomly walk away from the minimal energy state).

specifically, the temperature is

softmax(x/temp)

if you draw temp->0, your softmax slowly becomes an argmax (with temp=0 being a literal argmax). If you increase the temperature, you are closer to the "random fluctuations" leaving more room for sampling x values that are not the maximum of x. (this is why e.g. LLMs become deterministic as you decrease temp->0)

Using a different base other than e implicitly changes the temperature:

N^x = exp(ln(N) x)

The normalization works the same since you are still dividing a positive value N^x by the sum of all alternatives sum(N^x_i), which is a normalization by design

I'm what way is that different? You return early and the call Cascades up the call chain until you handle it (otherwise it's always an "either" results)

In practice you use something like an exception monad, which makes this a lot more ergonomic since you don't need to carry a case distinction around for every unwrap: an exception monad essentially has an implicit passthrough that says "if it's a value, apply the function, if it's an exception just keep that". You only need to "catch" the exception if you actually need the value. I'm this case the exception monad is not that different from annotating a function with "throws": your calling function either needs it's own throws (=error monad wrapper) in which case exceptions just roll through, or you remove the throws, but now need to handle the exception explicitly (=unwrap the monad).

Of course you can: you just have to define it in your type. The output set becomes a union type of the normal output and whatever you want as an exception.

If you write this as a monad, your get very similar syntax to procedural code.

Effectively none. The US has a huge trade deficit with Germany/Europe so there is practically never a case where the US receives gold from Germany: It's always more then offset by the deficit.

The equivalent for the US would be the consumption goods that are already flowing into the US. I.e. US gets goods but doesn't sell enough to Germany, so the difference to maintain the total exchange rate is the Gold.

That's also why it was trivial for france to repatriate its gold compared to germany: Germany holds about 10x the amount of gold in the US compared to France (France was ~120 tons, Germany is roughly 1200 tons: France earned its gold through different trade).

That's also why it is such a complex thing to repatriate German reserves: France took almost 1 year to repatriate its gold. For Germany, the efforts would be decade spanning (though maybe with recent changes there is a little more urgency).

Germany already repatriated about half of its gold reserves between 2013 and 2017 from paris and new york to frankfurt.

There has been a recent (as in "18th of march" recent) petition to the Bundestag to repatriate the gold.

The reason not to repatriate the remaining gold back then is because Germany has substantial trade with the US, which is why Germany held gold in new york to begin with: It's the easiest way to resolve USD-Euro currency exchange at the central bank level (this is also why germany got rid of the paris gold reserves: with the euro you don't need currency exchange anymore).

Also, as you mentioned, the idea of "officially" repatriating gold with the current administration is quite dicey. It is very possible that the correct way of resolving this is to just stop buying gold in new york and let the currency exchange flux deal with the slow unwinding of the reserves without explicit repatriation.

Whether the US is capable of hiding their maleficence or not should not be an indicator of whether it is safe to deal with them. If your indicator for the US being a good partner in _anything_ is that "well we did corrupt things in the past, but people didn't use to care about it", then the US is still not a good partner.

It's not like the US has never e.g. openly threatened NATO allies with war: There is quite literally a standing law that allows the US president to invade the netherlands if any US military personnel is ever detained by the International Criminal Court. This law has been on the books for over 20 years and has the publically announced intention to prevent the US from being prosecuted for all the other atrocities committed in e.g. Iraq. This bill was supported by both democrats and republicans.

The reality is that the US' stance towards the rest of the world has not changed with the recent administrations (nor would I expect it to: Trump does not happen in a vacuum). What did change was willingness of the rest of the world to act on the US' actions.

There were plenty of models the size of gpt3 in industry.

The core insight necessary for chatgpt was not scaling (that was already widely accepted): the insight was that instead of finetuning for each individual task, you can finetune once for the meta-task of instruction following, which brings a problem specification directly into the data stream.

Assuming this is real: Why do you think anthropic was put on what is essentially an "enemy of the state" list and openai didn't?

The two things anthropic refused to do is mass surveillance and autonomous weapons, so why do _you_ think openai refused and still did not get placed on the exact same list.

It's fine to say "I'm not going to resign. I didn't even sign that letter", but thinking that openai can get away with not developing autonomous weapons or mass surveillance is naive at the very best.

It might be that they pay less for anthropic depending how many tokens are generated by each model: total cost is token cost times number of tokens. I haven't checked gpt5, but it is not impossible that price wise they might be very comparable if you account for reasoning tokens used.

This is essentially the principle behind algebraic effects (which, in practice, do get implemented as delimited continuations):

When you have an impure effect (e.g. check a database, generate a random number, write to a file, nondeterministic choices,...), instead of directly implementing the impure action, you instead have a symbol e.g "read", "generate number", ...

When executing the function, you also provide a context of "interpreters" that map the symbol to whatever action you want. This is very useful, since the actual business logic can be analyzed in an isolated way. For instance, if you want to test your application you can use a dummy interpreter for "check database" that returns whatever values you need for testing, but without needing to go to an actual SQL database. It also allows you to switch backends rather easily: If your database uses the symbols "read", "write", "delete" then you just need to implement those calls in your backend. If you want to formally prove properties of your code, you can also do that by noting the properties of your symbols, e.g. `∀ key. read (delete key) = None`.

Since you always capture the symbol using an interpreter, you can also do fancy things like dynamically overriding the interpreter: To implement a seeded random number generator, you can have an interpreter that always overrides itself using the new seed. The interpreter would look something like this

```

Pseudorandom_interpreter(seed)(argument, continuation):

  rnd, new_seed <- generate_pseudorandom(seed, argument)
  with Pseudorandom_interpreter(new_seed):
       continuation(rnd)

You can clearly see the continuation passing style and the power of self-overriding your own interpreter. In fact, this is a nice way of handeling state in a pure way: Just put something other than new_seed into the new interpreter.

If you want to debug a state machine, you can use an interpreter like this

``` replace_state_interpreter(state)(new_state, continuation):

  with replace_state_interpreter(new_state ++ state):
       continuation(head state)

To trace the state. This way the "state" always holds the entire history of state changes, which can be very nice for debugging. During deployment, you can then replace use a different interpreter

```

replace_state_interpreter(state)(new_state, continuation):

  with replace_state_interpreter(new_state):
       continuation(state)

which just holds the current state.

Once you have strong normalization you can just check local confluence and use Newman's lemma to get strong confluence. That should be pretty easy: just build all n^2 pairs and run them to termination (which you have proven before). If those pairs are confluent, so is the full rewriting scheme.

That entirely depends on what AMD device you look at: gaming GPUs are not well supported, but their instinct line of accelerators works just as well as cuda. keep in mind that, in contrast to Nvidia, AMD uses different architectures for compute and gaming (though they are changing that in the next generation)

To expand on that: there's also the issue that these games have to be (somewhat) competitive multiplayer games: multiplayer because otherwise there's no way to create enough content, and competitive since otherwise there's less of a reason to play the game for long periods of time.

If you've ever played a dead/dying competitive game as a newcomer you will know the problem this creates: since the people that stay around are either new or very dedicated players, the skill gap becomes gigantic, which turns of most new players.

if your game wins the Life-Service race, you draw other players in. If your game dies the very same structure that keep players around will prevent new players from joining.

There are alternatives to iron that have higher efficiency and lower prices. For instance https://hydrogenious.net/ does exactly that but with benzene like structures. The advantage of this is that you can reuse existing infrastructure for transport and you have higher transport efficiency: while the square cube law exist, the same thing holds for the forces on the chamber walls which have to increase in thickness. Hydrogen tanks are also very expensive as they have to be manufactured to tight tolerances (and they need to be replaced rate often due to hydrogen creep weakening chamber walls)

The paper I have mentioned can be found here https://arxiv.org/pdf/2206.09787

There are so many things that have only been invented in the last couple of years like RINS, MCF cuts, conflict analysis, symmetry detection, dynamic search,... (see e.g. Tobias Achterberg's line of work).

On the other hand, hardware improvements were not as relevant for LP and MILP solvers as one would expect: For instance, as of now there is still no solver that really uses GPU compute (though people are working on that). The reason is that parallelization of simplex solvers is quite though since the algorithm is inherently sequential (it's a descend over simplex vertices) and the actual linear algebra is very sparse (if not entirely matrix free). You can do some things like lookahead for better pricing or row/column generation approaches, but you have to be very careful in that (interior point methods are arguably nicer to parallelize but in many cases have a penalty in performance compared to simplex).

MILP/MINLP solvers are much nicer to parallelize at first glance since you can parallelize across branches in the branch-and-bound, but in practice that is also pretty hard: Moderns solvers are so efficient that it can easily happen that you spend a lot of compute exploring a branch that is quickly proven to be unncessary to explore by a different branch (e.g. SCIP, the fastest open-source MINLP solver is completely single threaded and still _somewhat_ competetive). This means that a lot of the algorithmic improvements are hidden inside the parallelization improvements. I.e. a lot of time has been spent on the question of "What do we have to do to parallelize the solver without just wasting the additional threads".

2008 is ancient for optimization!

People have tested old year 2000 lp and milp solvers against recent ones while correcting for hardware. Hardware improvements made up ~20x improvement, while lp solvers in general sped up 180x. MILP solvers speed up a full 1000x (Progress in mathematical programming solvers from 2001 to 2020).

Solvers from 2008 are entirely different levels of performance: there are many problems that are unsolvable by those that are solved to zero duality gap in less than a second by more modern solvers.

In MINLPs the difference is even more standing. This doesn't mean that those books are useless (they are quite good), but do not expect a solver based on those techniques to even play in the same league as modern solvers.

You can solve L1 regression using linear programming at fantastically large scales. In fact in many applications you do the opposite: go from squared to absolute because the latter fits into in lp

The problem was mostly that the only guy that was really backing the project (Christian Ude, SPD), was replaced with his successor (Dieter Reiter, SPD) who just didn't have the drive necessary to maintain the project.

The entire design of "LiMux" was doomed from the start: it was a highly customized version of Ubuntu that was only used in Munich (not even throughout the entire state). That made everything ridiculously expensive since the actual advantages of building on an open source solution was never realized. That is combined with the fact that "open source" and "cost savings" were used interchangeably when in reality the budget for Windows should have been pre-allocated into development, rather than cut.

The entire project was half-assed to begin with, which basically meant that Windows and Linux had to coexist since many crucial tools were never ported to Linux.

The "Microsoft killed it" story sounds realistic, but the truth is the much more boring incompetence in execution.

The US could have required stock in Intel instead of taking nothing: Intel gets money, US gets influence over Intel. Just like it works everywhere else.

Not in the grand scheme of things: you can get fpga dev boards for $50 that are already useable for this type of thing (you can go even lower, but those aren't really useable for "CPU like" operation and are closer to "a whole lot of logic gates in a single chip"). Of course the "industry grade" solutions pack significantly more of a punch, but they can also be had for <$500.