mattalex

The reason the German gdpr watchdog is not complaining about Heise is because what they are doing is completely legal: you can still disable the tracking with the "more options" below.

Current legal doctrine is that _forcing_ payment (i.e. cash for privacy) is not allowed, that does not mean you cannot offer a subscription that disables tracking: you just have to offer a free option as well, which they do.

You assume that openai's inference is profitable and that they aren't just trying to bolster revenue before their IPO.

The only indication that openai is profitable comes from openai (whom I wouldn't trust with any statement, especially when it comes to profitability).

In fact there is evidence that inference is not profitable simply because the rate of losses doesn't seem to reduce as revenue increases: if inference had great margins, we would expect that as revenues increase, the amount of spend on training reduces as a fraction of total expenses. Since the loss-making fixed costs shrink as a fraction compared to the profitable inference, we should expect profitability to rise with total revenue.

However, all leaks of openai's numbers seem to suggest the opposite: as revenues increase so do the losses.

You can already do that: Keyword you want to be looking for is NTN (non terrestrial networks). The complexity is how you actually deploy this at scale and what you want the actual satellites to do: For example, there is the option of having the satellite be a "flying mirror" with minimal internal logic (transparent NTN: satellite is repeater) or a full gNB which can act as a "really tall cellphone tower" (regenerative NTN: satellite is basestation).

NTN satellites induce some quite significant challenges compared to standard 5G networks. I think most people can already imagine that delay is a considerable challenge, but that is ultimately relatively easy to deal with by adjusting the constants (like HARQ timers) in the 5G standard. A bigger issue are things like extreme doppler shifts induced by the high speed of LEO satellites (27000 km/h), which means that your UE has to continuously pre-compensate for doppler shifts. Another bit of weirdness is that cell handovers are now "reversed" compared to ground systems: In ground systems the reason you need to switch cells is usually because you moved away into a different cell. In LEO systems the "tower" and therefore cell moves. If you don't want to have constant re-negotiations with the cell, you need to have some sophisticated beamforming on the satellite to keep the cell steered onto the same ground area (i.e. the cell needs to move from the POV of the satellite to stay stationary from the ground side).

All of this is quite expensive, a lot more expensive than just having ground based hardware. From a purely economic POV these systems don't really make sense unless you have externalities like defense as a secondary argument. The catch 22 for NTN is (and arguably will always be) that it is the most worth it for regions far away from the existing network. However, since regions without cell coverage are almost surely not very affluent, they themselves cannot reasonably afford the extra expenses to justify a satellite communication system. There basically has to be governmental support from the defense or just "public good" coffers to make this reasonable. NTN will be a supplement for existing networks for the foreseeable future.

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.

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.

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.

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).