Hacker Newsnew | past | comments | ask | show | jobs | submit | orlp's commentslogin

GameStop doesn't have (even close to) $55.5B. Their offer from the letter is literally impossible:

> Our offer is $125.00 per share, comprising 50% cash and 50% GameStop common stock

Even if you magically included all existing GameStop stock in the offer, it still would not comprise 50% of $55.5B.

EDIT: looks like it's not impossible and I misunderstood. It's a proposed change of leadership with a $25B injection of cash to sweeten the deal. GameStop would issue shares which would capture the original eBay value (since GameStop would own eBay after the trade), making that part a wash. At least assuming people owning eBay stock currently would value the combined company at at least the sum of their parts, which is a big if.


> GameStop doesn't have (even close to) $55.5B

When the merger concludes, the former shareholders of eBay will have $27.5bn of GameStop-eBay stock and $27.5bn of cash. (“Cohen said GameStop has a commitment letter from TD Bank to provide up to $20 billion in debt financing” and “GameStop has around $9 billion in cash on its balance sheet to put toward a deal” [1].)

[1] https://www.wsj.com/business/deals/gamestop-is-offering-to-b...


I don’t understand why eBay shareholders will suddenly want GME memestock and find any interest in voting for this.

they will be getting 20% more than what Ebay is worth today

Once. Followed by a tank in price and descent into chaos.

You can sell the stock. This isn't complicated.

Won’t eBay shareholders own most of the combined company though? They won’t all be able to exit at the sale price.

True, it isn't complicated. With everyone rushing for the doors the price will rapidly tank.

Selling is a taxable event

Only for individuals, isn't it? Mutual funds etc don't have to pay CGT on everything, do they?

It looks like mutual funds pass the gains, and the tax, onto those holding shared of the mutual fund.

> Because mutual funds are pass-through vehicles, they are required by law to distribute most of these gains to shareholders each year. These are called capital gains distributions.

Other types of funds don't necessarily have this problem, or lessen it.

> Holding mutual funds inside an IRA, 401(k), or Roth IRA shields you from annual tax bills.

> Index funds: Passive funds trade less frequently, leading to fewer gains.

> Tax-managed funds: Specifically structured to reduce taxable events.

> Exchange-Traded Funds (ETFs): Use an “in-kind” redemption mechanism that avoids triggering taxable sales.

https://mutualfundnation.com/mutual-fund-capital-gains/


Neither is ignoring the offer and continuing to hold, if you’ve already been in for two, five, ten, twenty or more years like some have been.

I don’t understand either but wouldn’t they still be owning eBay? Just with GME?

They own eBay + GME + some financial alchemy. If you aren't a financial wizard you should assume that the value of the financial alchemy is negative. (Because 99% of the time it is.) Now, what are the synergies of eBay + GME that outweighs the chaos caused by the merger and the finance stuff?

I’m not totally sure how it would be structured but if GME is the purchaser then the merged company would be listed under GME and eBay would become a brand in the GME group and no longer a stock listed under the eBay ticker.

The whole thing seems incredibly dubious and fishy. The eBay board should vote this down which is why the CEO of GME has already realised that and said he’ll appeal to the shareholders directly. If eBay wanted to load themselves with twenty billion dollars of unnecessary debt and extra complications which would kill the company then they could do it themselves. They’re not in that kind of business.


There is, literally, nothing fishy about this offer. It’s a cash and stock offer from a public company to public company shareholders. We could call the financial or shareholder benefits to ebay dubious (I don’t hold any opinion about this) but this is a very aggressive offer, and allows the chance for GME to keep some cash - if enough shareholders of ebay opt for stock, then they’ll have cash available after. Plus they’d keep whatever current net assets ebay has.

ebay was at like 100 before the offer went out, it’s trading up to 120 or so in early hours this morning, so speculators and institutional desks do not find this offer fishy or dubious - they are pricing it as likely to be pretty well received.

As a side note, one of many plays you might make in this situation is what Cohen has done here; they bought a bunch of options. Those options are now worth a lot; before the letter if it was all options, they controlled $2b of EBAY shares, today that’s $2.6b. We might imagine the options at least doubled the underlying return. The market had not priced in a rapid jump to $120 when he bought them. If the deal closes, then this will put at least another billion or two of liquid capital into GME.


The end of your post negates the first line of it.

Its just financial engineering.

But his mention that it is a form of options is laughable. Thats not what is going on here.


Buying calls before a credible buyout pitch is a pretty standard strategy -- good leverage, what's laughable here?

The credible part.

TD Bank also believes it will work, i.e. return them a profit.

They've seen the detailed plans and I haven't. But they're the ones with real skin in the game. It seems like an opportunity for them to lose their shirts.

So yeah, eBay shareholders should take TD Bank's free money and run.



TD Bank believes it will make them a profit. Their interests are not those of eBay’s shareholders: if they can juice the financials long enough to sell their loan, they don’t care if the company goes bankrupt the minute after that sale closes.

Or ignore the free money/destroy company offer and hold.


That's just for the cash part. The stock part makes no sense. For this 50/50 deal to work in principle, they'd need to issue around a billion new shares, which would massively dilute the existing ~450M shares. So Ebay shareholders would suddenly own 70% of Gamestop after the deal. It's also highly questionable if investors actually believe the combined stock is worth that much, so the stock price would probably fall and turn those 70% into >90%. At this point it basically becomes a reverse acquisition plus a large loan for the final company from the cash part of the deal.

This is not atypical; smaller company “buys” the larger company with debt on the larger company’s books. The blended shareholder mix is mostly the larger company; management comes from the smaller company.

The one I was most familiar with was the Discovery “acquisition” of Warner Brothers. Though apparently that’s a little complicated because AT&T was divesting itself of Warner.


Yes. See [1] for an overview of how this works.

When the SEC filing is made, we'll get to see how the deal is structured. The $20 billion from TD Securities becomes a debt obligation of the combined company. There's a tax break in equity to debt conversion, and a second tax break for carried interest. [2] There may be a preferred stock deal or debt refinancing so that TD gets their $20 billion back. Usually, the private equity firm exits within a few years.

[1] https://pubs.aeaweb.org/doi/pdfplus/10.1257/jep.23.1.121

[2] https://www.pgpf.org/article/what-is-the-carried-interest-lo...


No, it's not a leveraged buyout

Sure it is. The acquirer is borrowing money for the buyout, and the debt will become a debt of the acquired/merged company. That, by definition, is a leveraged buyout.

That is not the definition of a leveraged buyout.

This is a public-to-public merger. Some mergers and acquisitions are financed with debt. That does not make them leveraged buyouts.

LBOs are private equity deals in which there's no issuance of public stock. The equity portion is, well, private equity.

Source: I've advised over 100+ clients on billions worth of M&A and LBO deals in my time as an investment banker in New York.


No, unless any control transaction using any leverage counts.

A third of the deal is financed with debt. A fifth is financed with cash. The bulk—fifty percent—is being financed with equity. An LBO would see debt and a thin tranche of cash finance the bulk of the acquisition.


The stock part is more like a merger than a buyout.

Yup.

It's newly issued stock, a common form of making acquisitions cheaper

How is a 20bn company going to issue 27bn worth of stock? Or are they just going to pretend the newly issued shares are valued the same per share as existing stock is right now?

Because it acquires an asset worth roughly that much, it’s neutral. GME is (probably!) not doing a huge at-the-market offering, they’re creating the shares and immediately giving them to eBay shareholders.

In practice the price paid for the company being acquired is usually a bit higher than the market value (so the shareholders take the deal), and the market usually punishes the acquirer a bit and the resulting entity’s stock will fall a bit. (This is most definitely not investing advice.)


the stock they'd be issuing would be for (GameSpot + eBay) whereas the current stock is for GameSpot alone

via a cunning pump on Wall Street Bets

Both stocks went up in value after the announcement, so it's a good sign that if it comes to it, eBay stock holders would vote for a merger, because they value the combined company at at least the sum of their parts.

why do i keep seeing comments of this sentiment? can't they just take loans? I thought there were serious consequences to making an offer, and then backing out , especially if the other party accepts your offer.

It’s wild to me that you believed that they would make an impossible offer.

man, those GME bagholders are gonna love diluted shares.`

They already increased total number of stock by +39% in last 12 months, GME will squeeze the last penny from those people.

… and the stock has not dropped 39%, in fact it’s trading about where it was a year ago. Shareholders have been content to let Cohen add to the balance sheet, adjust operations and make a large move. This is one such move. And GME is up 5+% in pre trading, so shareholders are generally positive about this idea.

If Cohen's "large move" was to buy EBay, investors could have done that themselves. They would have gotten a better deal on shares in the new company. Also, they'd be up 50% over 12 months. Partly because Cohen "adding to the balance sheet" has meant dilutions, and there will be more for this deal.

Yeah this is the funny part to me - if you thought EBay was an amazing business then you could have just bought that stock months or years ago. Maybe the combined company will really be worth more than both companies individually, but for the most part this is just GameStop deciding how you should have invested your money months ago.

Technically, we only know that the marginal non-shareholder is 5% more positive about the idea, since the price represents what the marginal buyer and seller are willing to transact at. The only shareholders involved in the increase are actually selling.

the shareholders of GME operate under the delusion that there's gonna be another magic short squeeze.

Waiting for the MOASS… it’s coming any day now!

I operate under the delusion that it was a $400 gamble and there is no point selling stock that I forgot I even owned at all, when it's such a small amount.

Perhaps that is part of the scam here. Meme stock buyers will think this means something and will spend more on worthless shares so that ebay executives can sell.

They can sell now and pocket some extra money. What's not to like?

If bagholders were capable of buying low and selling high, they wouldn't be bagholders.

you think all the bagholders are in at the current price?

If they didn't like the current prospects they can bail at a profit.

If they do like them they have no excuse if things go south.


Have your ever heard of debt? They have a 20B line secured from TD.

Yes, that goes into the '50% cash' part of the offer. With a 20B credit line and 7.5B cash from their own coffers (which they claim to have, so let's believe them on their word there), you cover the cash portion.

The issue is the non-cash portion of the offer. They claim that the remaining 27.5B is covered by GameStop stock. But that's more than double the market cap of GameStop.


With the approval of the board of directors (in most cases), a company can simply create new shares and give them to whomever they like.

I would guess that this information will bother you.

If it helps, because many public company executives are compensated on earnings per share, most C level teams are incentivized to buy back shares, thus decreasing the denominator for the EPS calculation without changing fundamental economics of the company.

If this also bothers you, you should guess what Buffet says and thinks about those two dynamics, and then read up on it, and you will learn something interesting about public markets!


I’m sure if eBay wanted to build 1800 brick and mortar stores they could do so for less than twenty seven billion dollars.

> which they claim to have, so let's believe them on their word there

So you're just outright accusing GameStop of fraud?

https://www.sec.gov/ix?doc=/Archives/edgar/data/1326380/0001... page 36 of their filing with the SEC lists the cash and marketable equities.

The non-cash (stock) portion of the offer needs to be valued against the resulting entity, which will own eBay. This will likely result in current eBay shareholders owning half or more of the resulting entity. (Though we don't know specific numbers yet). That's normal for a M&A where the smaller company is doing the buying.


> So you're just outright accusing GameStop of fraud?

I have no idea why you interpret my words that way. I just meant that I didn't want to analyze the cash portion of their offer any further and just wanted to take it at face value.


They don't claim to have it; they have it.

It's like saying 'tobacco allegedly causes cancer' - the proof is very public and available. The typical reason for saying it like that is to indicate you don't believe it.


You understand that the gamestop stock would then be owning ebay, thus be worth Ebay + Gamestops Valuation?

Alright, my company MEME offers to buy Apple then for $1 plus 100% of MEME's stock, which is worth more than Apple then since it will own Apple.

If you word it like this it's just a hostile proposed change of leadership. Weird way to apply to become CEO of eBay, but sure.


You can do that.

The shareholders have to vote for it, though.


They would also be owning a company that now would have +20B in debt.

They now own ebay. They would include in that math 20B in debt plus Gamestop.

This sounds like a pretty bad deal for ebay investors.


Are they under any obligation to ground the value of their own stock or can a salesman simply claim that the "true" value of that stock is much much more than it currently seems to be?

Stock is worth exactly what people will pay for it. Ebay share holders get to vote to accept or reject this deal

Presumably stock market valuation is grounding?

Also, eBay shareholders can vote down the acquisition if they don't think the deal is good for them.


What is your Python version? Splice was added in 3.10.

https://docs.python.org/3/library/os.html#os.splice


Edited with an update.

Vec::set_len is by no means deprecated. The lint you linked only covers a very specific unsound pattern using set_len.

Indeed, and it doesn't need to be deprecated, because it's an API explicitly designed to give you low-level control where you need it, and because it is appropriately defined as an `unsafe` function with documented safety invariants that must be manually upheld in order for usage to be memory-safe. The documentation also suggests several other (safe) functions that should be used instead when possible, and provides correct usage examples: https://doc.rust-lang.org/std/vec/struct.Vec.html#method.set... .

> and because it is appropriately defined as an `unsafe` function with documented safety invariants that must be manually upheld in order for usage to be memory-safe.

Didn't we learn from c, and the entire raison detre for rust, is that coders cannot be trusted to follow rules like this?

If coders could "(document) safety invariants that must be manually upheld in order for usage to be memory-safe." there's be no need for Rust.

This is the tautology underlying rust as I see it


No, this is mistaken. Rust provides `unsafe` functions for operations where memory-safety invariants must be manually upheld, and then forces callers to use `unsafe` blocks in order to call those functions, and then provides tooling for auditing unsafe blocks. Want to keep unsafe code out of your codebase? Then add `#![forbid(unsafe_code)]` to your crate root, and all unsafe code becomes a compiler error. Or you could add a check in your CI that prevents anyone from merging code that touches an unsafe block without sign-off from a senior maintainer. And/or you can add unit tests for any code that uses unsafe blocks and then run those tests under Miri, which will loudly complain if you perform any memory-unsafe operations. And you can add the `undocumented_unsafe_comment` lint in Clippy so that you'll never forget to document an unsafe block. Rust's culture is that unsafe blocks should be reserved for leaf nodes in the call graph, wrapped in safe APIs whose usage does not impose manual invariant management to downstream callers. Internally, those APIs represent a relatively miniscule portion of the codebase upon which all your verification can be focused. So you don't need to "trust" that coders will remember not to call unsafe functions needlessly, because the tooling is there to have your back.

> Want to keep unsafe code out of your codebase?

And how is this feasible for a systems language? Rust becomes too impotent for its main use case if you only use safe rust.

My original point still stands... Coders historically cannot be trusted to manually manage memory, unless they're rust coders apparently

> So you don't need to "trust" that coders will remember not to call unsafe functions needlessly, because the tooling is there to have your back.

By definition, it isn't possible for a tool to reason about unsafe code, otherwise the rust compiler would do it


> And how is this feasible for a systems language? Rust becomes too impotent for its main use case if you only use safe rust.

No, this is completely incorrect, and one of the most interesting and surprising results of Rust as an experiment in language design. An enormous proportion of Rust codebases need not have any unsafe code of their own whatsoever, and even those that do tend to have unsafe blocks in an extreme minority of files. Rust's hypothesis that unsafe code can be successfully encapsulated behind safe APIs suitable for the vast majority of uses has been experimentally proven in practice. Ironically, the average unsafe block in practice is a result of needing to call a function written in C, which is a symptom of not yet having enough alternatives written in Rust. I have worked on both freestanding OSes and embedded applications written in Rust--both domains where you would expect copious usage of unsafe--where I estimate less than 5% of the files actually contained unsafe blocks, meaning a 20x reduction in the effort needed to verify them (in Fred Brooks units, that's two silver bullets worth).

> Coders historically cannot be trusted to manually manage memory, unless they're rust coders apparently

Most Rust coders are not manually managing memory on the regular, or doing anything else that requires unsafe code. I'm not exaggerating when I say that it's entirely possible to have spent your entire career writing Rust code without ever having been forced to write an `unsafe` block, in the same way that Java programmers can go their entire career without using JNI.

> By definition, it isn't possible for a tool to reason about unsafe code, otherwise the rust compiler would do it

Of course it is. The Rust compiler reasons about unsafe code all the time. What it can't do is definitely prove many properties of unsafe code, which is why the compiler conservatively requires the annotation. But there are dozens of built-in warnings and Clippy lints that analyze unsafe blocks and attempts to flag issues early. In addition, Miri provides an interpreter in which to run unsafe code which provides dynamic rather than static analysis.


> No, this is completely incorrect,

Show me system level rust code that only uses safe then... You can't because its impossible. I doesn't matter that it's a minority of files (!), the simple fact is you can't program systems without using unsafe. Rewrite the c dependencies in rust and the amount of unsafe code increases massively

> Most Rust coders are not manually managing memory on the regular

Another sidestep. If coders in general cannot be trusted to manage memory, why can a rust coder be trusted all of a sudden?

> . But there are dozens of built-in warnings and Clippy lints that analyze unsafe blocks and attempts to flag issues early.

We already had that, it wasn't enough, hence..... rust, remember?


You are missing the forest for the trees here. The goal of that's unsafe isn't to prevent you from writing unsafe code. It's to prevent you from unsafe code by accident. That was always the goal. If you reread the comments through that lens I'm sure they'll make more sense.

I think you’re deliberately being obtuse here, and if you don’t see why, you should probably reflect on your reasoning.

I’ve been using Rust for about 12 years now, and the only times I’ve had to reach for `unsafe` was to do FFI stuff. That’s it. Maybe others might have more unsafe code and for good reasons, but from my perspective, I don’t know wtf you’re talking about.


> Maybe others might have more unsafe code and for good reasons, but from my perspective, I don’t know wtf you’re talking about

"well I don't need to use unsafe that much so I don't know what your point is" sounds like you don't really have an answer.


Rust has never been about outright eliminating unsafe code, it's about encapsulating that unsafe code within a safe externally usable API.

When creating a dynamic sized array type, it's much simpler to reason about its invariants when you assume only its public methods have access to its size and length fields, rather than trust the user to remember to update those fields themselves.

The above is an analogy which is obviously fixed by using opaque accesor functions, but Rust takes it further by encapsulating raw pointer usage itself.

The whole ethos of unsafe Rust is that you encapsulate usages of things like raw pointers and mutable static variables in smaller, more easily verifiable modules rather than having everyone deal with them directly.


The issue with C is that every single use of a pointer needs to come with safety invariants (at its most basic: when you a pass a pointer to my function, do I. take ownership of your pointer or not?). You cannot legitimately expect people to be that alert 100% of the time.

Inversely, you can write whole applications in rust without ever touching `unsafe` directly, so that keyword by itself signals the need for attention (both to the programmer and the reviewer or auditor). An unsafe block without a safety comment next to it is a very easy red flag to catch.


>when you a pass a pointer to my function, do I take ownership of your pointer or not?

It's honestly frustrating how prevalent this is in C, and the docs don't even tell you this, and if you guess it does take ownership and make a copy for it and you were wrong, now you just leaked memory, or if you guessed the other way now you have the potential to double-free it, use after free, or have it mutated behind your back.


The specific use case the GNU maintainer listed followed this exact pattern.

I've flagged the post, the title is editorialized, the title on the blog post is "MiniMax M2.7: The Agentic Model That Helped Build Itself" (at least at the time of writing this).


"Helped build itself" is arguably also a stretch as noted in another comment.


In university? No, absolutely not straight away.

The point of a CS degree is to know the fundamentals of computing, not the latest best practices in programming that abstract the fundamentals.


My university also taught best practices alongside that, everytime. I am very grateful for that.


Absolutely the wrong take. You can teach CS with just pencil and paper, but that doesn’t advance the technology, it might only benefit academia in a narrow sense. CS students should be actively engineering software in addition to doing science.


Why do you find it in interesting that someone chose something mainstream? Isn't that the definition of mainstream, that it's a common choice?


Anecdotally, I'm a fan and generally pick the rarer ones. Eg I had a pair of socks and a few stickers made for my kid which had rarer pokemon.

If OP got a tattoo of Pikachu, it was interesting to me that he picked the most mainstream pokemon (I assumed he was a huge fan)

But from the response, my sample of 1 assumption checks out: "When I was planning it was obvious there'd be a Pokémon due to his (continuing) interest in those and to me as a non-fan that's the most immediately-recognizable one."


In modern usage (e.g. in gaming communities) "carries" has become not only ambitransitive but also a noun.

If something "carries" or is "a carry", it means it is so strong it metaphorically carries the rest of the setup with it. For example:

> This card carries.

> These two are the carries of the team.


> N tokens looking at N tokens is quadratic

Convolving two arrays can be done perfectly accurately in O(n log n), despite every element being combined with every other element.

Or consider the even more basic sum of products a[i] * b[j] for all possible i, j:

    total = 0
    for i in range(len(a)):
        for j in range(len(b)):
            total += a[i] * b[j]
This can be computed in linear time as sum(a) * sum(b).

Your logic that 'the result contains terms of all pairs, therefore the algorithm must be quadratic' simply doesn't hold.


One of my favorite bits of my PhD dissertation was factoring an intractable 3-dimensional integral

\iiint f(x, y, z) dx dy dz = \int [\int g(x, y) dx]*[\int h(y, z) dz] dy

which greatly accelerated numerical integration (O(n^2) rather than O(n^3)).

My advisor was not particularly impressed and objectively I could have skipped it and let the simulations take a bit longer (quite a bit longer--this integration was done millions of times for different function parameters in an inner loop). But it was clever and all mine and I was proud of it.


That's like saying sorting can be done in O(n) because radix sort exists. If you assume some structure, you lose generality, i.e. there'll be some problems it's no longer able to solve. It can no longer approximate any arbitrary function that needs perfect memory over the sequence.


This brings me back to DSP class, man learning about FFT was eye-opening.


Convolution is a local operation.

Attention is a global operation.


An interesting follow-up question is, what is the smallest number unable to be encoded in 64 bits of binary lambda calculus?


BLC can output any literal 60 bit string x as the 64-bit (delimited) program 0010 x, so in that sense it would be some 61 bit number. But if ask about just lambda calculus terms without the binary input, then I think it would be some small number of at most 10 bits. BBλ looks at the normal form size so it cannot even reach numbers 0,1,2,3, and 5.


Bloom filters also become full.

As it fills up the false probability rate goes up. Once the false probability rate reaches the threshold of unacceptability, the bloom filter is full, and you can no longer insert into it.

That most interfaces still let you do something that looks like an insert is an interface failure, not a bloom filter feature.

If you find this controversial and want to reply "I don't have a threshold of unacceptability", I'll counter that a false probability rate of 100% will be reached eventually. And if you still find that acceptable, you can trivially modify any probabilistic filter to "never become full" by replacing the "is full" error condition with setting a flag that all future queries should return a false positive.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: