Join us as we gather around the hedge,
where we dig into technology, business, and culture
with the finest minds in computer networking.
Well, hello, Yvonne.
It's good to see that you're back with
us from your visiting from your other famous
and
highly successful podcast.
Ah, well, that's a bit of a I
don't know. I don't know what I'll say
to that. It's,
I'm glad to be here. How's that?
Yeah. I'm I'm famous. It sure feels like
it. Yeah. No. I am happy to be
here with with you guys. For us, it
is a Friday afternoon, and it couldn't come
any sooner. Hello, Tom and Audrey. So speaking
of famous, I have to say this morning,
at the start of another recording, another guest
was like, is that the plant?
So That I actually missed because of work.
But anyway, sorry about that. But yeah. If
you notice,
my plant
is no more.
No.
I know. It's terrible. So
we had a really big freeze back a
couple months ago,
and
my heater in my shed stopped working.
So I came out,
and then it had been all weekend,
and my plant was frozen solid.
It was, like, 17 degrees out here, so
it did not survive. So it's springtime.
I need to go find another plant, but
it did not make it.
So I'm sorry, everybody. The Dieffenbachia
is no more. I was just gonna say,
don't worry, Audrey. You're safe in here. You
don't need to worry about that. Yeah. Cover
its ears her ears.
So believe it or not, this is when
this publishes,
in theory, the three hundredth episode of the
hedge.
Isn't that crazy?
I feel I feel old.
Okay. I am old, so never mind. Hey.
I hit a bunch of big milestones this
year myself. So, yeah, we don't need to
talk about that anymore.
Yeah. I was at the gym yesterday, and
I was doing something. And somebody said I
was on the bench press, and I was
doing something. I was doing my reps, and
somebody walked over and said, alright. Man, you're
kinda old, like, for me in that kinda
way. And I was like, I'm just gonna
smack you upside the head. Maybe you meant
that as a compliment, but we need to
talk about how this works. Yeah.
You get around good for an old guy,
Russ.
Wow.
Okay.
So we're gonna we're gonna start today talking
about prompt injection in Bell Labs. And I
think this is interesting.
Well and then promptly destroyed it for a
profit. This is an article on LinkedIn, by
the way, if you wanna find it. I'll
try to put a link to it in
the show notes if I remember.
But anyway,
it's interesting to me well, let's talk about
the the what they've done
and what they did, and,
then we can talk about, like, why I
think this is this is or why we
think this is really interesting
in the in the realm of technology or
networking.
Lost my tab, guys. So
I know. It's terrible. I'm having to use
search to find my tab. Okay.
I've got it now. Yeah. It's terrible. Gosh.
Yeah. The whole the whole point of the
article is that,
it says Bell Labs self prompt injection
back in 1976.
And the whole
theory of the article
is
they invented technologies
back then. SS seven is a specific one
that we're talking about, where you had one
control channel and one data channel.
So all of the instructions
for the protocol and the service happened on
one channel. It ran its own protocol that
was completely architecturally
independent from the data channel.
And the and the the two did not
twain. Right? So you had your control channel
and your data channel, and those were separate,
which
pretty much prevents
the the possibility
of injecting,
bad instructions
in the data plane, right, or in in
the in in the information exchange because there's
a separate channel specifically for
control.
And, of course,
the business said what Well Go ahead.
The business said no. Yeah. So but but
to to even go to go back in
history and understand why this happened. When SS
seven was developed originally,
the
original
digital
signaling protocols, they weren't they weren't really digital
in those days, but let's let's say digital,
just to be kind.
You could call you pick up a phone
and and and dial certain tones
or inject certain tones
and make a payphone do a long distance
phone call, for instance,
without putting a quarter and without being charged.
And it was because the signaling was on
the same
channel
as the voice data. You pick up the
voice data. You pick up the voice voice
call, you pick up the handset, for those
of you who remember handsets,
speaking of
old,
you had a direct line to the switch,
to the telco switch, and you were talking
to the controller.
And so yes. So SS seven was developed
in part
against these tone kitties
or, you know, what we would call script
kitties today. Did you know that if you
pick up the phone and you go
at a certain frequency, it makes it bypass
the coin drop? You know, that was the
kind of thing that was passed around.
And so, yeah, they did they did this
by splitting
the control plane
from the data plane, and that still exists
in telco systems today.
They don't pay attention to it.
And if and if you're not familiar with
the story of Captain Crunch and the whistle
that came in the Captain Crunch box and
the lore,
behind that, it's it's worth looking up and
reading about because that's where a lot of
the,
you know, hacker
mentality
came from. It was one of the really
first well known,
hacks that got well publicized, and, and they
exploited this exact phenomenon that Russ has been
describing.
Yeah. Yeah. The the captain crunch whistle, and
people would take their modems, and there were
little programs you could get on
BBC, bulletin board systems, BBSs,
that would emit the correct tones. Right.
So that you could dial into the b
BBS system for free. Yeah. The thing I
I think is interesting about this bit of
history is we often think about,
rule 11 that there's not really new ideas.
They're just kind of recycled ideas and new
packages.
But I it extends to lots of different
things, not just protocol design.
It it extends in this case to how
to how to attack the vulnerabilities of a
system.
Like, it is it is you know, they're
the recipes for attacking a system also don't
change that much. There are new classes of
attacks, but, like, the the first principles of
attacking systems,
stayed basically the same. I think we're learning
new things. I'm not saying that there's only
old knowledge, but, certainly,
if you were trying to attack something, you'd
start from the playbook of what has worked
in the past. And you you a part
of the reason you would succeed is because
we don't learn the lessons of the past.
We're not very good at that.
Yeah. Exactly. Or we don't know how to
apply them. Or we think
but this is so different.
The problem we're solving is so different.
And, you know, and we we've come up
with a really unique solution.
No. Really, honestly,
you haven't. I promise you haven't come up
with a really unique solution.
Right? It's like it's like reading Shakespeare and
you hear people modern people go, well,
for the last thousand years, people have read
Shakespeare this way, but I found a new
way to read Shakespeare that actually explains what
it means.
I promise
you haven't.
So yeah. So continue, Yvonne. Sorry. You know,
they they broke it. So it took years.
Gosh. Where did I leave off? So,
yeah, so this we we we, ultimately, what
happened
is the business decided, like, hey. We've got
extra bandwidth out here. We've got this whole
channel
that we're using just for signaling.
We can shove
more revenue generating data down that channel without
spending any more money.
And so that's what the business did.
So and what that did
is it broke this separation in architecture
where you had control on one channel and
you had your data on another. And
here we are again, back to the same
place where you can inject
control language
into a control channel or into a shared
data and control channel
and,
and and break things or do bad things.
Yeah.
Yeah. I mean, originally, when they did this,
I bet
there was a conversation. He doesn't talk about
it in this article.
But
I bet there was a conversation that went
around a whiteboard or around a conference room
table
that said something like,
but doesn't this allow people to go back
to doing
the the,
the whistle in the phone thing?
And somebody probably answered and said, well, that's
not a part of the attack surface. This
SMS service is text only.
And the only way you'll get into this
SMS channel or be able to send SMS
data
is by is by being on the phone
and typing this stuff in. Like, there's no
interface
into that.
And, you know,
it's it's crazy
because anytime
anytime
that I have access to the physical endpoint
of the circuit,
I can inject anything I want to into
the circuit.
We we tend we tend to have this,
like,
oh, no. No. Nobody can get to that.
Well and and in my youth,
I've made this mistake as well. I remember
back,
it used to be that email systems were
purely text.
Right? Like, you you you read your email
in a text reader.
There was no ability to execute anything from
an email, and I remember
boldly declaring
that viruses could not be transmitted via email
because it was purely a text system.
Well, what happens is we get richer,
email readers,
richer text readers that are more integrated with
the client. And then all of a sudden,
you can start embedding
content that be can be clicked or launched
or executed from inside of an email. And
so it was really just a matter of
time. And, of course, I was the,
smart,
you know, computer science college student who was
like, oh, no. Email doesn't work that way.
You can never exploit it for by and,
you know, sending a virus in it because
there's no execute there's nowhere to do the
execution of whatever the thing is. Well, sure
enough, just one more small evolution ahead, and
all of a sudden, you have a whole
new attack service.
And then that's not even accounting for things
like,
you know, phishing attacks or social engineering attacks
or any of those things that can happen
over email. But it's it's really tempting
to fall for this kind of thinking. And
I think
most of us have probably done it in
one way or another
as,
what I'll say, early in career technologists.
Oh, we do we do it as late,
Yeah. We do it as late in career.
Hubris as we get more advanced may actually
make us more susceptible, not less, because we
think we know how it all works. Yeah.
Right.
Yeah. Oh, yeah. Yeah. Yeah. Yeah. I mean,
I remember I remember people deploying
individual boxes out to
rental car agencies
and saying, well, it has a password on
it, so who cares? You can't break into
it with a password on it.
Like, no. If I have physical access to
the box, I'm in.
Right? There are very few things you can
do. I mean, there are things you can
do.
You know, when I was at a company
once, we designed a system where you couldn't
break in, but it was because there were
there were,
motion sensors on the box.
And if you move the box, it erases
the data.
We'll break in all you want to now.
We don't really care because there's nothing on
there anymore. It has no circuit access anymore
because the data's gone.
And so, I mean, there are things you
can do, but they're radical. Like, they're crazy,
things that that are difficult.
But then this brings up the whole concept
of attack surfaces
and thinking through attack surfaces.
And then the idea of how you manage
most attack surfaces is via segmentation.
That's that's what we do. It's interesting because
you as you read the article, he talks
about this is actually is an architectural problem.
And specifically in in in relation to
prompt injection attempts. One example of this is
the GitHub data heist thing,
where you can you can you can put
stuff in a prompt that will that will
sort through GitHub that'll that'll find things,
and
you can you can inject prompts. It's just
like it smells just like a SQL injection
attack to me. You know, in back in
the old days, you'd put in a a
drop whatever semi colon in the input field,
and they hadn't scrubbed it. And so you
could do stuff to the database. Like, it
smells exactly like that to me. But the
thing that I thought was really interesting was
so there's a there's a whole series that,
Docker has put up called the, MCP horror
stories. It's pretty interesting. And they describe their
solution to this, and their solution to this
is put a gateway in. Put a gateway
in. It's just like a WAF is what
it reads like to me. We'll just inspect
all the control stuff that's going through this
consolidated control data channel, and every single control
message will just make sure that it's that
it's okay, which okay. And that's a pretty
normal reaction, but this is not a problem.
Like, you can you can somewhat solve it
with this idea of a gateway with the
middle box. But what the author of the
LinkedIn article is pointing out is there's actually
an architectural solution.
And and what you were saying, Russ, like,
yeah. We'll we'll we'll build it so you
can't break into it physically. That's a that's
a architectural solution. That's a, you know, how
the thing works. Yeah.
Quick.
Yeah. You can Well, we've also heard about
and I don't know that that we've reached
the attack level of this kind of thing
yet, but we've certainly heard
about AI systems misbehaving
because the context window gets so
large or or gets so congested
that the initial instructions that provided the constraints
for the system
fall out of the context window. Right? So,
hey. Don't don't or always ask before you
make changes.
Well, all of a sudden, you've you've you've
put so much data into the system that
you lose that instruction out of the context
window. And then all of a sudden,
your,
AI system starts behaving in ways that you
don't expect. Well, that sounds a lot to
me
like a buffer overrun.
Right? Like Yeah. It's it's it's the same
kind of thing,
where you're
expanding
the understood boundaries of the system and causing
it to behave erratically.
That's what a buffer overflow attack is.
Yeah. It's the same concept.
And so yeah. So and and think about
something like HTML.
Right? So we have the same sorts of
problems like like Tom was saying with, SQL
injection. SQL is the same thing. We use
a markup language that combines
the
instructions
with the met with the data that the
instruction is supposed to work on. It's very
object oriented. And we think, oh, object oriented
is a much better model for programming
because you contain the data with the code
and they're one unit. Right? So they always
know what each other are doing. But the
problem with that the the trade off there
is is exactly what this article is talking
about. Right?
You inject the data. Like, if we made
HTML, if we broke HTML into two pieces
and you said, I'm gonna have a
I'm gonna have a control channel
that says render this
and it says token $1.04 5 or token
$9.08 6 or whatever, and then you carry
the actual data for that token in a
separate channel,
and the tokens were well formatted and well
understood,
you'd get rid of 90% of the SQL
side channel, all these other weirdo attacks
that we get in CSS and SQL and
just all this stuff that we run into
on the Internet.
It's the same principle. Right? It's just separation
of concerns. It's using segmentation to your advantage.
And so yeah. I mean and by the
way, all this holds true in networks too.
If your network has been breached by somebody,
the number one way you can stop that
breach from being a real problem is by
segmenting so that people can't get done with
things. And Tom
was,
using the wife analogy. Right? And so, yeah,
you have the you have an option to
fix these kinds of vulnerabilities, weaknesses in a
system architecturally,
or you can fix them some other way.
But when you fix them whatever that other
way is,
typically,
you're injecting more state into the system, which
is gonna make it more fragile,
or you're injecting more complexity
or computational
power required,
which is gonna make the system less performant,
and
really
is
gonna work most of the time,
but probably not a 100% of the time.
Right? And we've seen this over and over
and over with security technologies,
whether it's
stateful packet inspection,
whether it's proxy servers,
whether it's,
you know, I'm I'm thinking about it. So
then then then we go to what?
Layer seven firewalls, right, that inspect all the
traffic. And then we, you know, and then
we've got, you know, SQL injection protection. Right?
All the different layers
of protection
that
are imperfect
and are ultimately
workarounds
to an architectural solution,
that could be more elegant, more performant.
Yeah. Yeah. Yep.
And performance is a big issue too.
Like, you know, a lot of DDoS protection
things, they do things that are definitely
they reduce
performance
overall
in order to protect you from DDoS.
And that's, you know, alright. There's the trade
off. Right? I don't I don't want the
DDoS attack, but then
do I always want the performance hit?
And we you know, we don't really it's
another issue that we don't really think about.
Yeah. So I think this is I think
this is incredibly interesting,
just from a design
paradigm,
understanding
how to design things,
perspective
on,
you know, not just
protocols,
not just,
the networks, protocols,
applications,
security, they're all of the above. Even your
physical security.
Even your physical security falls to this. Right?
You you have to you have to make
sure that your
control plane is not tied up
with your
data channel as much as you possibly can.
There are some places where you can't avoid
it at the point of access.
But once you get behind the point of
access,
like, you know, these should be different things.
So, yeah, I think it's I think it's
an important thing.
So okay.
Second topic
is unfortunate.
It's sad and unfortunate.
So I saw this article in Network World.
I
didn't get I I guess I could suppose
it's by rational effect. It's not by rational
effects but the analysis is done by rational
effects.
And so I'm not entirely certain
the timelines of all these and everything like
that. But the article headline is is that
there are tech playoffs surpassed 45,000
in early twenty twenty six.
And the immediate
reasoning that that is used here
is that
firms across the industry restructure operations and shift
resources towards
AI and automation investments,
which I think is, like I think a
lot of people are saying that. I think
it's about what what is provable at this
point. Yeah. I think a lot yeah.
Yeah.
Well, essentially, they say investments,
not
they're not saying
we're replacing the people with AI specifically, although
that has been a thing in a lot
of layoffs.
But that we don't have money for people
because we're investing in AI.
Because what? We
expect AI
to,
you know,
take over? Like, what what are we thinking
here? Well, I think depending on the organization,
some of it is just flat out CapEx.
Right? Like,
we're letting people go because we need more
GPUs.
You know? I I I think some of
it is going to CapEx.
I I think some of it is opportunistic.
And what I mean by that is,
hey. We we've overhired, or we're not sure
that we're getting the value out of all
the people that we have on payroll, and
this gives us a an opportunity to to
trim things down. I think we are we
are still in the middle of an era
where that's happening.
And and then I think some of it
too is
there's this promise,
some of which I think will be realized
that AI is gonna optimize
some knowledge work.
And I think,
you know, there's this there's this leadership philosophy
that, like, peep people people use the time
that they have. People use the resources that
they have. It's like, you know, time is
kinda like closet space. You're gonna absorb
whatever you have with what you're given.
And so I think organizations are thinking, well,
if we if we cut headcount, that's gonna
force the people that we have today
to be more efficient. And I think I
I think there's there's some truth to that,
but I don't know that
some of our organizations really even understand what's
going on enough to make those decisions in
the best best way.
But I think all of those things are
part of what's happening.
I I I find it interesting if if
somebody is saying we're gonna force our people
to use,
AI by giving them more
work.
You know, but most people see when they
see a layoff is an input to the
amygdala in their brain that says, danger. You're
probably next. I don't know of
anybody who makes fundamental
paradigm shifts in how they work
under threat.
And, like, so the so I I totally
believe that what you're like, some people are
using this rationalization,
Yvonne. Like, it seems like a very
rational thing for someone to say, oh, yeah.
We'll do this, and then this will happen.
But I don't know. I have a hard
time seeing that actually laying out like they
see like, they're predicting in reality
just because of how people look how people
look at things. And not right now is
not a great time to lose your job.
And, you know, I I don't think people
think straight when you might get you might
get laid off next week. I think that's
absolutely true. I actually went on a rant
privately with a friend today about my frustration
with engineers
who make decisions that impact people
and
don't think through the human elements of it.
Right? Like,
people
first of all, like, reads some Kahneman and
Diverski.
People aren't rational.
They don't make economic decisions rationally. They don't
necessarily make career decision rationally.
And we we rationalize things as if people
are going to decide to behave rationally.
They do not, first of all.
And then,
also, there are,
second and third order order effects of of
these kinds of changes that may not be
seen immediately, but ultimately bear themselves out in
compliance and reliability
and,
you know, the the ability to execute in
certain ways.
Yeah. So it's, it's just a really interesting
time. Yeah.
So if you're saying to somebody,
for instance,
you can do four times as much using
AI.
In the inverse, if I were to think
about that, and there's a way to think
about that, which is that my time is
worth four times less.
And and so
there's a bit of a there's a bit
of a struggle there on how,
as a human, you should see that and
understand that
and not be defensive
about it.
And and I'm not sure exactly how you
do that
as a person.
And then, again, the person, as Yvonne is
saying, is making the decision,
and they're not thinking about second and third
order effects. There's been this thing about,
Sam Altman said the other day on some
clip, he said, you know, we see knowledge
as a service that you can buy like
water or electricity
effectively
or or intelligence. He didn't say knowledge. He
said intelligence.
And I thought, wow.
You know?
I'm not sure that intelligence is is amenable
to that kind
of commoditization.
And and then other people will say, well,
once we get AIs in place, I can
cut my workforce in half and sell just
as much. And then then you have to
ask,
who are you selling to?
If everybody cuts their workforce in half
Mhmm. Then who has the money to buy
your products? Right.
Like,
how does that work?
So, like, there's all these weird second order
knock on effects
that
are un I'm sure they're unintended consequences, but
nonetheless, like,
there are things that are happening. I think
there's another knock on effect, which is what
happens when so right now, your shareholders would
be very pleased with you cutting cost massively
because they're not in your business. They're in
the business of turning their money into more
money. So the shareholders like to see,
cost go down because they can at any
time get out
and get what get you know, give make
whatever gains they were gonna make, whereas employees
can't just get out instantly on a dime
like investors can, like shareholders can. And so
but what happens when you when you gut
innovation? I saw another I saw another article,
maybe we could talk about it another time,
about,
research and development,
someone who worked at HP who sees what's
happening at Intel.
You know, what happens if you if you've
got research and development. But in this case,
you're going to get innovation
if you tell people if you if you
do all these things to the workforce, you're
gonna get innovation.
And that works for the short term. You
probably will cut cost. Your investors will be
happy.
Everything will be fine. But once everything's commoditized
down to the same large language model doing
the same thing for all the companies,
then you've lost the ability to climb out
of that hole. And then what happens then?
Now this happens in ten years or twenty
years. It doesn't happen this quarter. But I
think that's a I don't know. Long term
I don't I don't I wonder how many
people are thinking long term about what these
strategies are leading us towards.
Yeah. I was also part of a a
conversation with a colleague the other day, and
we were talking about
gains in
in,
specifically, developer productivity
and what that means, but, also,
the entire
system that exists around the developer.
Right? And so if you think about
agile programming methodology and what existed before that,
all of that really came out of
what we call, like, the Toyota Way, books
like the goal by Goldratt. Right? And what
we what we learned from
that manufacturing
world
is that
part of pushing code through a system is
doing things like reducing
work in progress,
managing your backlog,
making sure that
every stage in the development process
is working together,
and you're not you've not got these big
huge backlogs of work that are piling up.
Well, what AI is doing
is it's moving the choke point. In other
words, maybe writing the code
is no longer
the
slowest part of the process,
but there are other parts of that process,
whether they're QA and testing, whether it's the
speed at which users can consume the changes,
whether it's, you know,
how you're meeting your compliance requirements and standards.
There's a lot of work that goes around
the work of generating code.
And so, ultimately,
if all we're doing is
shoving more code through the system,
we're just creating new places for there to
be backlogs.
And so it's not gonna improve the overall
speed of the system
the way we think it is. And in
so many ways,
a lot of what's going on with AI
right now, we're just creating new local optimization
problems.
Right? Like, because we're optimizing in a different
place,
but that doesn't mean that the whole system
is speeding up. And I don't think anybody
can know what that looks like yet because
it's so new.
And so we're making assumptions that the whole
system is gonna improve in productivity.
I don't believe that that is gonna be
the case. I think there will be improvements
in productivity, but I think we got a
long way off
before we fix the whole system. And so
I think we're making some assumptions that are
gonna end up
causing
challenges in the future because
we're we're gonna end up with huge backsell
backlogs of work just in different places.
Well, it's and, yeah, it's even I think
it's actually even worse than that in a
sense that
we used to avoid tech debt
like the plague.
Like, tech debt was horrible. We would spend
many, many,
many, many hours of developer time refactoring code,
not because it was broken per se,
but because nobody understood it
because it was tech debt. Now we almost
seem to celebrate tech debt.
Oh, you don't know how it works? Yay.
Like,
really?
And I'm gonna go, well, the the the
humans can can code review the code that
they don't understand because some AI system is
writing it.
Yeah. I'm not I'm not really sure how
this is gonna work. I
worry a lot about that sooner. Thought all
the way through this analogy. And and But
it's just like a different kind of inflation.
Right? Like, the perception
of the value of that the the perception
of the cost of that debt is lower.
But is it really? Right? Or is just
everything
more expensive? Right? Like, there's is is is
there just more money in the system? Right?
And so it seems like it's cheaper,
but there's just more in the system.
But we don't really know whether it has
the same value it used to. I actually
think that analogy
might hold together better than I thought it
did when I first said it out loud.
Yeah. No. No. It does. Because because it's
the same thing with photography
and motion pictures and music and,
you know, even,
dare I say it, even truth itself
to some degree. Right? Even truth itself.
When you get to the point
where
you wanna cover up one incident
by publishing
10,000
similar incidents, none of which were true,
and that the one the ten thousandth becomes
implausible
because there were 999,000
whatever it is, nine nine thousand nine hundred
ninety nine that were not true,
there's an entire different
perception
or texture
to the to the way we see things
once that happens.
And that's that that worries me a lot.
Maybe that's a different show, though, is to
talk about
AI and perception and
and What is reality, Russ?
Stuff like that. Just unpack that for us
and we'll call it a day.
Well, are you a realist or an not
or an anti realist?
Do you do do you are you a
nominalist or a practical nominalist? You knew what
you were getting into, Yvonne, when you asked
that question. Yeah. Yeah.
I know. I
I was just trying to get a laugh.
So alright. Cool. So I think we've hit
both of those pretty well. So anything else
to anybody wanna, like, say anything about those
two before we call show 300
done?
Nice round
number. I I will end by saying I
don't think the end of civilization
as we know it
is as near as we believe. I think
it's probably gonna be different. Like, you know,
just like the just like the Internet changed
civilization and just like mobile changed civilization. I
think AI is going to make some changes,
but I think at the end of the
day,
we're still gonna be people, and there's still
gonna be interesting work to do. And it
may,
shove around in the different places and look
a little different in the future, but I
think the,
the the predictions of the end of society
as we know it are
a bit
overblown.
That's what I will say.
Yeah. We'll see.
I also feel pretty optimistic about things.
I think,
you know, this for for many people, they
didn't live through most of us didn't live
through the transition from the agricultural age to
the industrial age. And so we don't know
what it was like we didn't witness the
human race surviving that. And so,
I think
I think we're there's just a lot of
opportunity. I think there's and in fact and
I think there's a lot of opportunity if
you think differently than other people do. If
your background and your training is different than
the mass of people,
or if you if you're just if you're
just not on the same path everybody else
is on, right now is a great time
to be you. I think we have to
think about problems. Now we're gonna be forced
to think about problems from different perspectives.
And because the traditional ones have all been
commoditized
and people who are a little different, I
think, are gonna have an edge.
Hooray for optimism. Yeah. Could be.
Alright. Well, Yvonne, where can people follow you
if they want to or get in touch
with people? I'm on LinkedIn. You can find
me at Yvonne Sharp, and that other podcast
you heard Russ refer to is called the
Cloud Gambit over on the Packet Pusher's network.
I hang out. I look I look
on x Twitter x quite a bit, at
Sharp Network.
I don't post as much as I have
in the past, but you can certainly find
me there. So, yeah,
I'm I'm around it online. Yeah. You can
follow Yvonne on her on her famous podcast.
Yeah. I was gonna say, I thought we
should call it the podcast that shall not
be named.
I have nothing to say. Just kidding. The
podcast
we should tell Ethan to change the name
of Packet Pushers to the podcast form There
you go. On his Packet Pushers. Nah.
Nah.
There's hey. It's a big tent. There's room
for all of us. Come on.
Alright, Tom. Where can people get in touch
with you or follow you?
LinkedIn.
I think Audrey holds the timer. She does.
That's that's what I think it is. I
think I I think Audrey has the timer.
Alright. I'm Russ White. You can find me
on LinkedIn. You can find me at routing
geek on x occasionally, not all the time.
I do post there from time to time,
but not all the time. And
you can always find my email address or
whatever if you wanna get in touch. I'm
super, super hard to find. Trust me. I'm
I'm very hard to find. So, anyway, we
know we live in an attention driven economy.
We thank you very much for listening all
the way to the bitter end of this
episode of the hedge. Hedge 300. There's 300.
If you have not listened to all 300
of these,
this is what you're doing this weekend.
And
so thanks for listening, and we will catch
you next time.