HolyLampshade

I think that's precisely what the previous commenter is saying. Sit on the side lines, and let other people bloody themselves up.

Similar in a way to dot com. It's not to say ML won't have practical application in the future, but the likelihood that it will have specifically this form is low and worth waiting until the dust settles and a more commonly accepted utility presents itself.

If AI/ML were monstrously useful in its current form the companies pushing it would not need to be hawking products; people would be bashing their doors down. I think that's why in areas where it's more directly applied to a known problem set (like Pharma research, and I'm hoping someone with Pharma expertise can pipe up here) there has been more natural pickup.

Coming from trading and markets, ML has been a part of the mix in quantitative strategies for...well, nearly 20 years (by definition I suppose). Spaces with obvious utility will see rapid adoption. Worth waiting that out, honestly.

One of those silly little issues with inbuilt software that drives me insane is the number of times I’ve had to log back into Apple Music or Spotify (or one of the video services to occupy the kiddo while parked for extended duration).

That’s another one that phones have just solved with the integrated password manager. The friction of providing credentials on my other devices has been reduced, but all of a sudden I need to go hunting through that pwd manager, and hunting and pecking on the infotainment keyboard, to enter a 20+ char unique pwd that modern “best practices” has established. It got bad enough for a bit (swver changes resulting in needing to re-log in) that I stopped using all of these apps for 2-3yr on our Model Y because I got tired of having to do it.

I think what’s become more interesting/impactful for me is why they elect not to support it.

Most firms moving away from it (or who never implemented it) seem determined to either sell additional subscription services to their user base (connectivity) or sell their user base to a third-party (either as data, or eyeballs). And for a product at this price point I find myself very annoyed at the attempted payment extraction.

Either way, I’m with you. Lots of vehicle manufacturers out there that will support it.

Amusingly for the security information processors in the US (which handle US Equity consolidated quote and trade data) the trade feed is still referred to as the tape (one of the two governing bodies is called the Consolidated Tape Association). Securities are still associated by which ‘tape’ their trades print on (really which one of the two SIPs the trades will be found on).

It existed prior to GME as well, which really should tell you that anyone who is using this is going against people who have spent the last decade at least perfecting signals based on this exact same data.

The hope isn’t that you find some unique signal to trade on. The hope is you find some signal that does not scale in a meaningful way, so it is less likely professional firms are going to devote resources to trading it.

If you stumble into a fresh, scalable signal it’s unlikely it will continue to be profitable after six months. Once you scale to any real profitable size the market will notice and either change behavior, or trade the same signal at a faster speed.

And to extend this, low frequency does not mean slow speed. HFT mostly covers how often you are trading. Some low frequency strategies require near instantaneous (sub microsecond) execution capability in order to beat people trading on the same signal.

While true (I 100% agree with you in the distinction), the statement is “Your agent acts before the market does”, which is simply not going to be the case (assuming this is helping run some sort of trend following strategy). Professional traders who are sensitive to alternative public data sources are already taking that data in quickly and their execution is colocated with the venues. You’re still going to be significantly behind the curve (to a financially dangerous extent in my opinion).

I was trying to think of a way to word this exact argument. I think it’s especially easy when your business technology is not your primary means of revenue generation. Having these execs understand how things work is significantly less critical in these scenarios, so it becomes much easier to hire for alternative characteristics (golf game, pedigree, gender, whatever).

Easier to justify monthly costs than big capital asks (even if your infra is depreciated at a normal rate) is where I think many saw (incorrectly) cost savings. It’s also a bit of these execs mortgaging the future, banking on either being out of their role when the real cost comes due or that people will have incredibly short memories (not a wild assumption).

I've never seen anything like it for a technically optional tool

Cloud had a very similar vibe when it was really running advertising to CIO/CTOs hard. Everything had to be jammed into the cloud, even if it made absolutely no sense for it to be run there.

This seems to come pretty frequently from visionless tech execs. They need to justify their existence to their boss, and thus try to show how innovative and/or cost cutting they can be.

Interestingly the realm in which I have domain experience has similar constraints, but based primarily on physical transport latency and less on bandwidth. There has been a move in some spaces towards hyper-dense deployments, but it’s a very small amount of the total compute capacity due to other limitations.

Still, the world I’m used to operating in is typically 5-10 kVA/rack.

Oh, I have no doubt it is functionally efficient. I'm just amazed given the system deployments I've been party to, and the tiny amount of per rack energy usage comparatively speaking given the functionality of those systems.

Like, what in the good god damn are we using all this energy for?

200 kW/rack is absolutely insane to me. The power consumption of these facilities is just...ridiculous.

That is interesting. Never considered trying to throw one or two into a loop together to try to keep it honest. Appreciate the Visor recommendation, I'll give it a look and see if I can make this all 'make sense'.

I think that's the issue I have with using these tools so far (definitely professionally, but even in pet projects for embedded systems). The mental load of having to go back through and make sure all of the lines of code do what the agent claims they do, even with tests, is significantly more than it would take to learn the implementation myself.

I can see the utility in creating very simple web-based tools where there's a monstrous wealth of public resources to build a model off of, but even the most recent models provided by Anthro, OpenAI, or MSFT seem prone to not quite perfection. And every time I find an error I'm left wondering what other bugs I'm not catching.

I know I'm running a bit late to the party here, but maybe someone can provide some color that I (on the slightly older end of the spectrum when it comes to this) don't fully understand.

When people talk about leaving their agents to run overnight, what are those agents actually doing? The limited utility I've had using agent-supported software development requires a significant amount of hand holding, maybe because I'm in an industry with limited externally available examples to build am model off of (though all of the specifications are public, I've yet to see an agent build an appropriate implementation).

So it's much more transactional...I ask, it does something (usually within seconds), I correct, it iterates again...

What sort of tasks are people putting these agents to? How are people running 'multiple' of these agents? What am I missing here?

That explains why the effects looked so similar in the two...

Never did get into Babylon 5, but SeaQuest, for all its campiness, was my jam briefly in my childhood.

Can't speak for ML training, but I absolutely love using the OODA loop as a simplification of the decision and operating pattern in competitive industries. Boyd really did put together an easy to understand framework to help describe where an organization/process needs to tighten up.

Yeah, I think the issue has more to do with the curiosity level of the participant rather than whether they are a business domain expert or a software engineering expert.

There’s a requisite curiosity necessary to cross the discomfort boundary into how the sausage is made.

I worked in the Swedish office of a multinational for a couple of years and the one experience I had where Swedes were selling a complex multi-million euro project to Germans was one of the most bureaucratically filled initiatives I’ve ever experienced in my life. Not sure if the project ever really took off, but I’m thankful I was able to avoid it beyond the initial week of discussions.

This is not uncommon between even allies: https://www.dw.com/en/german-intelligence-spied-on-white-hou...

The issue has less to do with intelligence silliness, and more to do with the fact that the overall geopolitical objectives of the US can not be trusted, and that rift has grown to a point where self-reliance on critical infrastructure may be in Europe’s best interest.

I’m a tad late to the party, but it’s worth providing a little context to the technical conversation.

Of the many thing trading platforms are attempting to do, the two most relevant here are the overall latency and more importantly where serialization occurs on the system.

Latency itself is only relevant as it applies to the “uncertainty” period where capital is tied up before the result of the instruction is acknowledged. Firms can only have so much capital risk, and so these moments end up being little dead periods. So long as the latency is reasonably deterministic though it’s mostly inconsequential if a platform takes 25us or 25ms to return an order acknowledgement (this is slightly more relevant in environments where there are potentially multiple venues to trade a product on, but in terms of global financial systems these environments are exceptions and not the norm). Latency is really only important when factored alongside some metric indicating a failure of business logic (failures to execute on aggressive orders or failures to cancel in time are two typical metrics)

The most important to many participants is where serialization occurs on the trading venue (what the initial portion of this blog is about; determining who was “first”). Usually this is to the tune of 1-2ns (in some cases lower). There are diminishing returns however to making this absolute in physical terms. A small handful of venues have attempted to address serialization at the very edge of their systems, but the net result is just a change in how firms that are extremely sensitive to being first apply technical expertise to the problem.

Most “good” venues permit an amount of slop in their systems (usually to the tune of 5-10% of the overall latency) which reduces the benefits of playing the sorts of ridiculous games to be “first”. There ends up being a hard limit to the economic benefit of throwing man hours and infrastructure at the problem.

The issue here for me has always been about the difference between treating a symptom and treating the illness.

Excessive surveillance is necessary when you cannot convince people of the merits of your politics or morals on their own and need to use the power of the State to intimidate and control their access.

For the issue on minors, if you have a child (guilty here) you are obligated to actively raise and educate them on the nature of the world. For access to online interactions this doesn’t necessarily only mean active limits (as one might judge appropriate for the child), but also teaching them that people do not always have positive intent, and anonymity leads to lack of consequence, and consequently potentially antisocial behavior.

A person’s exposure to these issues are not limited to interactions online. We are taught to be suspicious of strangers offering candy from the back of panel vans. We are taught to look both ways when entering a roadway.

The people demanding the right to limit what people can say and who they can talk to do so under the guise of protecting children, but these tools are too prone to the potential for abuse. In the market of ideas it’s better (and arguably safer, if not significantly more challenging) to simply outcompete with your own.

For what it’s worth I went through the upgrade last weekend. There is a compatibility check script and, frankly, the whole process proxmox had described on their site worked precisely as advertised.

5 host cluster; rebooted them all at completion and all of the containers came back up without issue (combination of VMs and LXC)

In fact, it won’t be. Which is why NYSE was so quick to rebrand NYSE Chicago as NYSE Texas when TXSE made the announcement they were launching in Equinix NY4 in Secaucus. The only real differentiator these guys would have had (outside of listings rules) would have been location, but they opted for the lower resistance of locating with all the other markets.

I completely agree with you. 21 years ago when it was released it was simply “yet another competitor” to the sort of overlay systems that gamespy and the like were trying to implement. You installed it because Half-Life 2 (and the litany of mods that became empires into themselves) required it, but it took years for it to develop in a direction that pointed to where we are now.

The first time I did a rebuild and now no longer needed the installation media for games, or the license keys in the manual/game jacket, and I was fully sold.

I don’t fully grasp the hatred, because almost every aspect of it is a vast improvement over what existed 20 years ago. But fortunately there are alternatives.

A long time ago I had a colleague turn me on to Sidney Dekker’s “Drift Into Failure”, which in many ways covers system design taking into account the “human” element. You could think of it as the “realists” approach to system safety.

At the time we operated some industry specific, but national scale, critical systems and were discussing the balance of the crucial business importance of agility and rapid release cycles (in our industry) against system fragility and reliability.

Turns out (and I take no credit for the underlying architecture of this specific system, though I’ve been a strong advocate for this model of operating) if you design systems around humans who can rapidly identify and diagnose what has failed, and what the up stream and down stream impacts are, and you make these failures predictable in their scope and nature, and the recovery method simple, with a solid technical operations group you can limit the mean-time-to-resolution of incidents to <60s without having to invest significant development effort into software that provides automated system recovery.

The issue with both methods (human or technical recovery) is that both are dependent on maintaining an organizational culture that fosters a deep understanding of how the system fails, and what the various predictable upstream and downstream impacts are. The more you permit the culture to decay the more you increase the likelihood that an outage will go from benign and “normal” to absolutely catastrophic and potentially company ending.

In my experience companies who operate under this model eventually sacrifice the flexibility of rapid deployment for an environment where no failure is acceptable, largely because of an lack of appreciation for how much of the system’s design is dependent on an expectation of the fostering of the “appropriate” human element.

(Which leads to further discussion about absolutely critical systems like aviation or nuclear where you absolutely cannot accept catastrophic failure because it results in loss of life)

Extremely long story short, I completely agree. Aviation (more accurately aerospace) disasters, nuclear disasters, medical failures (typically emergency care or surgical), power generation, and the military (especially aircraft carrier flight decks) are all phenomenal areas to look for examples of how systems can be designed to account for where people may fail in the critical path.

We've been able to run order matching engines for entire exchanges on a single thread for over a decade by this point.

This is the bit that really gets me fired up. People (read: system “architects”) were so desperate to “prove their worth” and leave a mark that many of these systems have been over complicated, unleashing a litany of new issues. The original design would still satisfy 99% of use cases and these days, given local compute capacity, you could run an entire market on a single device.

I’m not sure I follow the logic here. Let’s say a person owns a Tesla outright, and purchased it ignorant to Elon’s behavior (esp if prior to the last year or two). How does selling it benefit some cause? Tesla already has that person’s money. It’s purely a performative action?

I can’t remember who first said it, but watching crypto evolve is like speedrunning why 150yr of securities laws, practices, and regulations exist.

Counterparty risk (including custodianship) is monstrous in crypto. It’s sort of amusingly ridiculous in the same way most tech trends that are trying to break the status quo stumble into the reasons certain rules and regulations exist.