Writing bugs with K.S. Bhaskar

Justin Garrison (00:03.804)
Hello and welcome to Fork Around and Find Out, the podcast all about taking you back in time on what it's like to write bugs for the last five decades. Today on the show we have Bhaskar, who we met in person like many of the guests, which is great. I met you at dinner and you said something that stuck with me still to this day, where you said you've been writing the finest bugs since the 1970s. And I love that. So thank you for coming on the show.

K.S. Bhaskar (00:28.791)
Thank you for having me. It's good to be here. And of course, the software business, we create bugs, right? That's what we do.

Justin Garrison (00:35.772)
That's it, no features, just bugs. And sometimes they're usable bugs.

K.S. Bhaskar (00:38.286)
Exactly.

Autumn Nash (00:41.93)
wish that we could just say that quote to computer science classes because I think it would help a lot of imposter syndrome.

K.S. Bhaskar (00:47.843)
you

Justin Garrison (00:49.284)
I like you you will write this wrong five times and then you will read it, right? But it'll still be wrong in the future. So don't worry It's not it's either a bug right now or it's a bug later

K.S. Bhaskar (00:55.38)
Exactly.

Autumn Nash (00:58.594)
The amount of engineers, I think especially women that I talked to and they're just like, is it normal to feel bad so much? And I'm like, yeah. There's a lot of failing like, and then you feel like a God for like two seconds and then there's a lot of failing.

K.S. Bhaskar (01:06.488)
Hehehehehe

you

Justin Garrison (01:13.286)
Yeah. Yeah. When the build works and you're like, understand that piece of it. And then the next thing is just like, I don't get it. Anything. Nothing works.

K.S. Bhaskar (01:20.878)
You

Autumn Nash (01:21.612)
honestly think that should be part of teaching engineering though, like we're almost doing them a disservice when we're just like, and then it'll build, like, cause I mean, like that happens a lot less than the failing part. So if like we were more, I guess, transparent on that cycle, I think that people could find more joy in being an engineer, you know?

Justin Garrison (01:29.234)
You

K.S. Bhaskar (01:30.625)
you

K.S. Bhaskar (01:42.527)
In the old days we used to say if it compiled, ship it.

Justin Garrison (01:46.096)
Yeah. Yeah, if it compiled, that's the test right there. If I have something that executes, right, I that's good enough.

K.S. Bhaskar (01:49.87)
you

Autumn Nash (01:54.188)
Which is wild with the amount of testing and pipelines that we use now, you know, someone's dying when they're hearing that.

Justin Garrison (02:01.65)
Oh man, like a flaky test. You're like, oh, we can't just stop everyone stop. Cause this doesn't work all the time. And one of the things, one of the things I want to talk to you about is just how software has changed over a period of time that you've, you've been able to experience and, and how you've kind of changed with it, right? Like the industry, even in last 10 years is different 20 years ago, 30 years ago, it completely not even recognizable.

K.S. Bhaskar (02:28.718)
Well, here's something too, which is when I got my first job programming. I was a student at my undergraduate university in India. And I got my first job as a programmer in 1971 part-time, and I was paid two rupees an hour. Now, at that time, the biggest computer that we had on campus was an IBM 7044, which today would be dwarfed computationally by a smart doorbell.

Justin Garrison (02:55.026)
you

You

K.S. Bhaskar (02:58.85)
computer time on that sold for 2000 rupees an hour. Okay, so a thousand times more than I was paid. And so the lesson always was, what would a professor has told us is if you can spend two hours debugging or fixing something to save a couple seconds of computer time, it's worth it. And, know, today it's completely the other way around.

Autumn Nash (03:06.187)
That is.

Justin Garrison (03:22.566)
Yeah, that's probably the biggest change, Because now somewhat one person's time is worth so much more than the compute.

K.S. Bhaskar (03:29.57)
Right. You know, and I think nothing of, you know, I make a change. I just run a compile to see if I got the syntax right. And, you know, those days I wouldn't even think of doing that because one of the things you had to do was, you know, we had punch cards and you wrote your, your program on punch cards. You turned it in and you would basically get a printout the next day. And so if you didn't get it right, then you had to wait yet another day for the program to run.

Justin Garrison (03:31.026)
That's fascinating.

Justin Garrison (03:41.521)
You

Justin Garrison (04:00.127)
Has that made us worse as engineers? Like, I feel like because we don't value like the computer, like we just, we're just like, just either throw money at it or try it again or do little things over and over again. Is that, is that as an engineering culture?

K.S. Bhaskar (04:16.514)
Well, it's good and bad. mean, there are things where, you know, certainly I'm a lot more productive now. And I think that the code I write today is probably a lot better than the code I wrote 50 years ago just because, you know, I can test it better, I can run more cycles on it and so on. On the other hand, you know, there are certain things where you have to, you know, let's say if you're doing something that is really critical.

it really does pay to stop and think about it and think through it before you just write the code. And certainly in the business that YaraDB is in, we go into a lot of mission-critical applications in banking and healthcare. And so it's absolutely critical to us to get the code right. of course, so it works one way in the sense that we can do a lot more testing now than we've.

could have done years ago. But on the other hand, it also means we have to spend a lot more time thinking about the code and thinking about the design even before we start coding. And in the old days, we didn't think about it that much because, again, programs are also simpler.

Justin Garrison (05:28.114)
Sure. Was that simply, was the simplification because of they were not used as in many places or was that just because they were isolated and not as dependent on other pieces of software and things?

K.S. Bhaskar (05:41.644)
Well, you literally couldn't create a big program. So like the IBM 7044 computer, its memory was something like 32K words, and each word was 36 bits. So if it didn't fit in memory, you essentially had to sort of overlay parts of the program, bring in bits and pieces. So what you actually did was write your program in lots of little things, and you went from.

Justin Garrison (05:57.361)
Yeah.

K.S. Bhaskar (06:09.274)
You process something and then put it on tape and then you process something else. So you couldn't do anything that is particularly big. And I guess in some sense what comes around goes around because that's what microservices is. Except in our case, we did one service at a time instead of running them all in parallel.

Justin Garrison (06:14.022)
Mm-hmm.

Justin Garrison (06:20.849)
Yeah.

Justin Garrison (06:27.066)
Maybe microservices would be better if we counted how much memory they used in words. Or is that you get 50 words of memory. Just a...

K.S. Bhaskar (06:32.75)
You

K.S. Bhaskar (06:36.927)
You

Autumn Nash (06:38.067)
It's just mind blowing. Think about the fact that we were counting words and that kind of processing and then like the huge data sets we're processing right now for like machine learning. those two, like the fact that they're in a span of your career is absolutely amazing.

K.S. Bhaskar (06:56.75)
It's been a lot of fun. What I tell people is, you know, I'm 70 and I got into computers. So, okay, so here's the reason I got into computers. The computer center was the only air-conditioned building on campus.

Autumn Nash (07:14.763)
that that is why okay but like have you ever heard anyone that's come on this show that's really done great things everybody's got like the most unique reason for starting and I love that like nobody's just because like

K.S. Bhaskar (07:18.283)
I didn't.

K.S. Bhaskar (07:27.822)
you

Justin Garrison (07:30.13)
I I got into computers because the computer lab was across the hall from my dorm room and I could do my homework while I got paid. And it was just like, could get paid and do homework. And that's the perfect thing as a college student. And I just sit there. But air conditioning, that is the best example.

K.S. Bhaskar (07:46.392)
Well, mean, on the campus there, routinely in summer, the temperature would get to over 100 degrees. And again, this is India, and it was less developed in those days than it is today. So we would often have power cuts in the dorm from like 5 o'clock in the morning till 11 o'clock in the morning. So no fan even. So the computer center has got electricity. It's got air conditioning. It's a great place to go hang out.

Justin Garrison (08:06.578)
Cheers.

Justin Garrison (08:12.27)
How did the university get a computer at that time? I did not grow up around computers. I was born in the 80s. everything, it seems like that seems like a really big privilege for that university to have that big of a computer and air conditioning and constant power at that time.

K.S. Bhaskar (08:28.206)
Oh, it was. So this was the Indian Institute of Technology in Kanpur. And it was set up as part of with aid from a consortium of nine American universities, know, MIT, Ohio State, Purdue, I forget there was a list of nine. And they, somewhere in like the mid 1960s, they had a spare IBM 1620 computer. Now the IBM 1620, by the way,

goes back, it's a 1950s design. It was IBM's first scientific computer. So anyway, they had one to spare and they shipped it and installed it on campus. So that was the computer that I used to write my first program. And at that time in India, there were probably about, if I remember correctly, somewhere around 120 or 130 computers. And my university had three, so we were quite privileged. But it was...

Justin Garrison (09:19.6)
Wow

K.S. Bhaskar (09:25.27)
One of those things where the government of India set up these institutes to sort of be like the next, to train the next generation of engineers. so ours was set up with American collaboration. There was one that was set up with British collaboration. Another one, you know, German, another one Soviet. And then there was one that was set up with UNESCO collaboration. And so essentially in each of these universities, the country as part of their foreign aid program would provide expertise and...

and equipment and so on to set up the university.

Autumn Nash (09:56.672)
Were there a lot of differences between the contrast of the different countries, I guess, and their...

K.S. Bhaskar (10:02.73)
I think the big difference was what they specialized in, what are some of the prestige courses. So in my university, electrical engineering was considered the prestige course. In the Indian Institute of Technology in Bombay, which is set up with Soviet collaboration, chemical engineering was a prestige course. In the one that was set up with German collaboration, for example, mechanical engineering was considered a prestige course.

All the universities had all the different branches of engineering and we had a very competitive exam to get in. they would like, know, an entrance exam there was something like 40,000 people would sit for the exam and out of those maybe a couple thousand would get in. And depending on your rank in the exam, you got to select which course at which university you got into.

Autumn Nash (10:55.735)
Wow, you must have been, you've done really well.

Justin Garrison (10:57.084)
So you took the exam.

K.S. Bhaskar (10:59.438)
I did pretty well. So I actually, you know, I was the only one I remember in that year that came in the first hundred in both the entrance exam for the Indian Institute of Technology as well as there was another thing called the National Science Talent Search, which is kind of modeled on what used to be the Westinghouse Science Talent and then is the Intel Science Talent. So I actually...

That particular year, I came first in the country on that. So was the only one that managed to come in in the first hundred on both.

Autumn Nash (11:30.647)
That's so impressive. Did you have previous experience in electrical engineering before that?

K.S. Bhaskar (11:37.684)
No, no, actually it was a long story, it's a short story actually. My passion in high school was physics, that's what I wanted to do in college. And so when I came first in the science talent, that's really what I wanted to do. And then my dad said, well, you're going to do electrical engineering and you're going to do electrical engineering at this university. And I argued with him for several days, but ultimately I had no choice.

Justin Garrison (11:54.842)
You

Autumn Nash (12:03.308)
man.

Justin Garrison (12:03.538)
but then you still pick the building that had AC.

K.S. Bhaskar (12:06.422)
I picked the building that had AC and again, at that time there was no undergraduate computer science program, so electrical engineering was the closest you could get to computer science. And in fact, that is a time when I actually had the opportunity to sort of unite both. So Stanford University shipped us an old PDP-1 computer that they had worked on and they had heavily modified. So they shipped it to us when...

They didn't have any further use for it. And a bunch of us spent like a year putting it together. It filled a whole room. And Stanford had modified it. So here's something for debugging software. One of the instructions that Stanford had added to it was called fiddle following. So if you executed a fiddle following instruction, the next instruction could be something completely different from what was one of the official instructions of the instruction set. So it was a lot of fun.

Autumn Nash (13:02.721)
So what kind of, maybe the other people know what this is, but what did it entail to take a whole day to put together, or that whole time to put together a computer?

K.S. Bhaskar (13:16.822)
Well, mean, we actually had some, you when it was shipped to us, it wasn't really like Lego where you had to put it together. The computer was kind of created and put together. But what it did mean was that if the program didn't work, you had to go look at the hardware, not just the software. So a flip-flop was essentially a circuit board about this size. It used germanium PNP transistors and

And if the flip-flop circuit was loose, your program might not run properly.

Autumn Nash (13:50.153)
wow, that makes debugging way more complicated. Like I feel like I should be more grateful for the things I have to check at this point.

Justin Garrison (13:55.155)
Well, and like it... It just goes into like...

how much software engineers were also hardware engineers, right? You had to know how the hardware worked. Autumn, I finished the book you bought me for Christmas, The Superman, which was a story of Seymour Cray. And a lot of the things that he talked about, they deciding on, they want silicone transistors or germanium transistors? It was like a big deal for them to decide because everything else was germanium at the time. Like, no, we're gonna go with silicon, right? And it's just fascinating how those ripples have kind of affected so many things.

K.S. Bhaskar (14:03.16)
Yeah.

Justin Garrison (14:28.844)
And I remember one of the big problems they kept having in the the Cray computers that they're building was just the heat dissipation. They're like, well, we were hand soldering all these transistors. These were not integrated circuits. These were big pieces of equipment. And they had to have like AC specialists on hand to be able to like, how do we cool this much heat in this much electricity? Awesome.

K.S. Bhaskar (14:46.947)
Yes.

Justin Garrison (14:53.09)
And this also points out to me just, think you are living proof of investment in other countries and being able to allow, not allow people to, but just like giving people access to things they may not have access to before.

like your career is like proof that that works and that that is something that is continued even today that should be invested in long term for all people, not just to like say, you know, only people that live in this area can have access things. And you didn't get access to the top tier hardware at the time, like you were getting secondhand computers, but it still like allowed you to do so much more than what Stanford was gonna do with that PDP one anymore, right?

K.S. Bhaskar (15:36.846)
Sure, absolutely. And in fact, I remember back in I forget, 1980s and 1990s, one of the things that we were doing was getting used computers and then shipping them to places like Central America and Africa and so on, where one of those things would actually be very useful. And I recently ran across a kid that was getting old laptops and sending them to India.

Autumn Nash (16:04.087)
I would argue not only is it an investment because look at how great it is that you got a career, I mean, look at how much you've given back to the industry. You know what I mean? So it's not like they just gave things to you. You've given back so much, which shows that it is such a great... People just look at kind of helping others or kind of making that democratization of tech as like, oh, well, we're helping people, but they help us back. We have had so many technological breakthroughs, science breakthroughs.

Justin Garrison (16:18.17)
yeah.

Autumn Nash (16:34.005)
that add to everyone. Like this is a team sport of like discoveries. We do so much more when we work together.

K.S. Bhaskar (16:41.068)
absolutely. And I think that helping other people be productive helps us be productive as well. And certainly living in the US, it's easy to forget that. And certainly living in the US under the, I don't know what your particular political leanings are, but certainly living in the US at the present, where we tend to say, let's not worry about people outside. I think it's a mistake because ultimately,

You're absolutely right. We do live together and we sort of build on each other.

Autumn Nash (17:16.191)
I was actually thinking that this is such a great conversation for the time that we're in because how many cancer researches, how many, just all kinds of research were saying that, you know, all these wonderful students got here on merit. They got here because they were amazing at their field. And we knew that it was this great investment because they were going to give 10 times more than what they've put in and that we were going to make these breakthroughs. And it just makes me so sad that we are going to lose so much advancement because we can't.

look at this in a community kind of way and we're looking at it in a selfish way.

Justin Garrison (17:48.189)
Well, the desire to save a dollar is just ridiculous to think that we don't make that money back. Yeah.

Autumn Nash (17:57.578)
It's not even a dollar though, because if you look at how much people pay into like taxes when you're like not a citizen, it's actually we're going to spend more money to get rid of people that we really need that make things better.

K.S. Bhaskar (18:12.142)
Sure, I absolutely agree.

Justin Garrison (18:15.282)
So in 71, you started writing bugs and then you caught the bug for programming. How did that go on? What was it like for you, your career in, let's say, 80s and 90s? What was the next kind of wave that you were doing?

K.S. Bhaskar (18:29.422)
Sure, so just in a nutshell. So actually I started programming in 1970. 1971 was when I got my first job. so I came to the US as a grad student in 1975. And that was like this great big shift in technology because I was using these old computers at college in India. And I came to Carnegie Mellon Computer Science Department in the US. And there we had deck tens and then

using them, using a terminal interactively, that was something that was completely new to me. And then actually I went on to the University of Nebraska where we had like a personal APL machine. There's a programming language called APL. we actually had a machine that ran APL and that was my first computer that I saw that was a standalone desktop computer. Yeah, so we moved on to that. And then I went to work for

Justin Garrison (19:12.124)
Hmm. Yeah, yeah.

K.S. Bhaskar (19:27.63)
a company in Seattle called Fluke for many years, and we built electronic test equipment. And I actually spent a good chunk of my time working on test equipment in particular. For example, there's test equipment for the Boeing used in the 757 and 767 to test the radio altimeter. So I led the software on that. And it's a time of significant change. we actually

retargeted a compiler that we actually did the first piece of test equipment that was written in a high-level language. Until then, people had done it all in assembly language. So we actually took a C compiler, and then we retargeted that from the 8080 to the Z80, and then wrote that. And it was kind of interesting because we had 48 kilobytes of RAM and 16 kilobytes of RAM. And so we'd write the software, and then we'd say, oh crap, it's like six bytes bigger than 48 kilobytes.

Justin Garrison (20:23.758)
jeez.

K.S. Bhaskar (20:24.654)
So then we would sit at it and we wrote a people optimize, know, and then we do people optimization. We'd say, okay, here's the sequence of code which can be shrunk by this little bit. So we'd add that to the people optimizer and then it would run a compilation and then we'd say, wow, okay, now we have 10 bytes to play with. it is different.

Justin Garrison (20:35.513)
wow.

Justin Garrison (20:47.014)
So at that point you're trying to out-optimize the compiler.

K.S. Bhaskar (20:52.322)
We were trying to, well, basically as part of the compiler, we did a people optimization phase at the end of the compilation. so did that. And then ultimately at some point, and I went on to work for other hardware companies that were doing software. And then I realized back in the 1980s that I really needed to work for a software company because one of the problems of working for a hardware company, it's an accounting problem. Companies are slaves.

to their accounting systems. So if you think about it, a hardware company like Fluke, they would burden their labor costs based on, because they had to have all these massive equipment for building equipment. And so let's say the labor costs they would charge is like, let's pick a number, $75 an hour. Now, if you think about software in those days, you wrote the software, but then the manufacturing cost of the software.

is just you duplicate a floppy disk, you print it manually, shrink wrap it in a box, and you ship it. So maybe it's 15 minutes of time. But if you're charging your labor at $75 enough, and there's 15 minutes of time that does not require heavy equipment, all of a sudden, you're going to conclude that software is not a profitable business to be in. And so I decided to move into the software world, went to work for a company that did electronic.

test and measurement software. In fact, that company had the first fast Fourier transform that ran on a PC and then moved into databases. They've been working in databases for the last 30 years and that's what Garadibi is, we're a database company and you're basically making very high-end key value databases.

Justin Garrison (22:41.33)
So what was that switch like going from like a lot of testing software to database? was in, I mean, databases weren't new, but I do feel like databases have gone through a lot of changes over the last 20 to 30 years.

K.S. Bhaskar (22:58.316)
Well, in our case, we've actually stayed with the key value technology just because there's a lot of software that was written back in the 1980s and 1990s. I we still use that today. One of the things that's fashionable these days is to say that this software is old, so therefore it must be bad. And that doesn't make any sense. I the analogy I use is to like bicycles, right?

If you look at a bicycle, for one of my presentations, I have a photo of a bicycle from the 1920s. And I have a photo of a bicycle from today. And it's one of those things where if you were to see that bicycle from the 1920s, you would have no problem riding it. And conversely, the guy from the 1920s were to see the bicycle today, maybe he'd have to understand how gears work, but he'd have no problem riding a bike. And so, old isn't necessarily bad. And so one of the things that, at least in the database business that I've been in,

We run a lot of legacy applications. of that code, parts of it may have been written in the 1980s, and maybe today it's 100 times bigger than what it was in the 1980s. But the code is something that is living, it has grown, it has a lot more functionality. And we continue to insist that the code that is written in the 1980s continues to run today. So it's very different from the type of database business that you...

you tend to see outside where, you here's something new, let's pick it up.

Justin Garrison (24:35.058)
I would say databases is usually a little more conservative in wanting to try the newest greatest thing because the closer you get to critical data, the more important it is that that code is tested well and kind of battle tested in the real world.

Autumn Nash (24:50.047)
It's also a pain to migrate. Like migrations are so painful and they take so long.

K.S. Bhaskar (24:56.984)
Well, and among other things, you have to make sure that you migrated correctly, right? If you have terabytes of data, you can't just say, know, CP from this file to this file, and suddenly you've got the database moved over. So, and you know, we run, and especially because we're running in banking and healthcare, we have to also be very conscious about security. So it's not just that it has to be right, because your bank balance is just a few bits on a disk.

it also has to have other safeguards.

Justin Garrison (25:32.708)
So how do you, like maintaining databases and maintaining code bases for decades, like how do you take a different mindset to how you're going to maintain something that long, right? Because there's so many things today that's like, maintain some open source project for maybe six months, a year, maybe a few years, but something like, hey, if we want to maintain this for 30 years, what kind of things do you need set up upfront?

Autumn Nash (25:57.984)
Also, how do you maintain it through all the changes? Because the world's changed so much, you know?

K.S. Bhaskar (26:04.878)
Well, certainly the... Well, one is, of course, evolution. mean, it's not like suddenly things change and something is broken. But the, you know, the code base has evolved. It originally, you know, if you go back 30, 40... The code base actually is almost 40 years old when it was first written. And it ran on a Motorola 68000 VMS computer system.

And then it was migrated to a VAX and then to an alpha. And then it was migrated to UNIX. And then like 25 years ago, we migrated that to Linux. And so with each of these migrations, there's certainly evolution that comes along. But part of what you have to do when you maintain a code base with that law is, well, let me take a step back.

and talk about software testing, right? So if you want to maintain code for that long, you've got to have a lot of testing that goes with it. So the goal of testing is not just to prove that the software does what it's supposed to do. You also have to prove that the software, you have to have confidence that the software doesn't do what it's not supposed to do. And then the question is, how do you have that confidence that the software is not doing what it's not supposed to do? Because you can't possibly test for all of those things.

Justin Garrison (27:21.966)
Infinite. Yeah.

K.S. Bhaskar (27:25.304)
So the way that you do that in practice is you test that the software does everything that it's supposed to do, as well as a few diabolical cases that you throw at it. And so even if you make a small change somewhere, you still have to go through the entire test cycle to convince yourself that you haven't broken something somewhere unrelated. So there's a certain mindset. There's a certain way of writing software. You tend to stick to

Let's say non-APIs, you don't necessarily go chase the newest shiny thing that comes along. So those are all the ways that we keep the lasting for a long time. And I think that if it's properly written, it should still be running 100 years from now. I won't be around 100 years from now, but the code should still be around and still be running.

Autumn Nash (28:19.447)
One of my favorite parts of talking to you so far is people won't be able to see it because of podcasts, but you have just the kindest face. And when you talk about the technology, you still look excited. And I love that because people will be like, well, what do you want to do when you retire? And I was like, I hope I never retire. I don't want to work nine to five forever, but like, I hope I get to kind of always play with technology and. Yes.

K.S. Bhaskar (28:35.264)
you

Justin Garrison (28:40.69)
You hope you never retire from excitement, right? Like from learning things and from enjoying it. Yeah. Yeah.

K.S. Bhaskar (28:44.257)
yeah, yes,

Autumn Nash (28:44.681)
And your face looks genuinely excited and enjoyment. How have you, I guess, pivoted? I've watched your talks long ago just because being in the database world. And the way that you speak of technology just makes me excited about it. How have you kept that excitement? Because you do great things. You advocate for open source. You advocate for access to like in...

Allowing people into IT technology like you've done a lot of so many amazing things in your career and you still have that same excitement Like you just started yesterday. How do you keep that going?

K.S. Bhaskar (29:22.338)
Well, there are two reasons to be in business, make money and have fun. you know, you have to, with the make money part, you you need enough to keep a roof over your head and put bread on the table, but I'm not out to, you know, buy a Caribbean island or something like that. And, but the fun part is, you know, I found something that I enjoy doing. And once I found something that I enjoyed doing, I kind of stuck with it. And what I tell people is that,

I would like to keep writing software until it's time for me to be carried out horizontally because that's what I enjoy doing. And that's my bucket list and I'm able to do that. So it's not right for everyone obviously, but it's right for me.

Autumn Nash (30:10.753)
They say that if you, they have that saying like, if you do what you enjoy, you never work a day in your life and your face just like, I hope to have a career that's half as cool as yours where I still look that excited. Like what is it that you love so much about databases and open source? Because like you are just such a component for Linux databases and open source.

Justin Garrison (30:11.002)
One thing you-

Autumn Nash (30:33.685)
And I love the quote where you always say that open source is good for business. And I think we're kind of in a weird spot in open source right now. So like, I would love to hear kind of like, what keeps bringing you back to that and like what joy you find in databases and open source in Linux.

Justin Garrison (30:38.972)
Yeah.

K.S. Bhaskar (30:48.866)
Well, databases just happens to be something that I stumbled into when I was looking for a job. And then it got me interested. And once I got interested, I kind of stayed interested with it. But what I like about open source is that it transfers power from the hands of the developer to the hands of the user. And that was brought home to me when I was running a small business in Massachusetts many years ago.

bug tracking in our software, had this software that cost like $1,000 or $2,000 or something like that. I forget the amount, but it was something that a small company could afford. And then that company got bought by another company that got bought by a bigger company. And suddenly this $2,000 piece of software became an enterprise software with like a quarter of a million dollar entry price. And about that time, I was also

Justin Garrison (31:40.794)
suck all the fun out of it.

K.S. Bhaskar (31:46.706)
I started using Emacs, I was influenced by Richard Stallman and some of the work that he was doing. And I realized that you really need to shift the balance of power from the developer to the user. And the way to do that is open source or free software, free as in Libre, not free as in Beard, though the two go together. And so that's how I sort of became a convert to using open source.

Now the transition to doing open source as a business came later and that was mostly, I was working for this company, our software was proprietary and then we got bought by this other company because they wanted the technology, they were our biggest customer. And they didn't want to market that software, they just said we'll continue supporting our old customers. But then what I could see was that over time,

And this goes back to like 2000. Over time, what would happen is that as the bar for quality kept getting higher and higher, if the number of users stayed the same or shrank, then eventually what is going to happen was that you're going to be spending all of your time on quality and on testing and less of the time on the software itself. So we had to expand the user base. And the parent company was kind of skeptical about open source, but I said, hey, let's go.

open source, let's release the software, we'll get a lot more users. And so they went along with that and surprise, surprise, all of a sudden, we got a lot more users and some of those users turned into customers because they were running these critical applications and needed someone behind them. And that was when I became a fan of open source as a business. And frankly, what we do is we sell peace of mind.

So if someone is using our software and they're using it because their business depends on it, they need someone behind them and by having us behind them, they have peace of mind and that's what we're sailing.

Autumn Nash (33:55.935)
I wish.

Justin Garrison (33:56.179)
That's what a lot of these are, right? Especially open source where the lower in the stack and the more critical the software is, the more people need to be able to sleep at night knowing that database is gonna have my data tomorrow, right?

K.S. Bhaskar (34:08.49)
Exactly, exactly.

Autumn Nash (34:09.439)
I wish people would like remember what you just said about open source because I think that everybody is in this rush to change licenses on people and they forget the reciprocal and like relationship people that there is with people being your customer and contributing to your code base and using your software.

K.S. Bhaskar (34:29.784)
Sure, and in fact just using software has value because if you use the software and you report issues, that has value to a software developer.

Justin Garrison (34:42.694)
Yeah. You said you were influenced by Richard Stallman and I just recently read the Cathedral in the Bazaar about open source software as opposed to the Free Software Foundation and what Richard Stallman was doing. How did you see that play out in what businesses were thinking? Because when I think of open source software and kind of the boom, I think of...

not Mozilla, you know, like the browsers, the browser wars in the nineties where there was these open source options of like there was internet explorer and Microsoft, and then there was the open source version. And that was really how like people saw open source could be a business. Cause there was this thing that was challenging the big monopoly. How is that? How have you seen that change over the years?

K.S. Bhaskar (35:29.56)
Well, actually, interesting that you mentioned the Cathedral of the Bazaar because ESR just lives a few miles down the road from where we are.

Justin Garrison (35:36.216)
if you know him, him come on the show. I'd love to talk to him.

K.S. Bhaskar (35:39.438)
Well, I sort of know him. I gave him a ride once to the Southeast Linux Festival many years ago. Sure, I'll mention it to him. send him an email. No, I think the big cultural change, if you remember Steve Ballmer many years ago saying Linux is a cancer, and then many years later, you

Justin Garrison (35:51.088)
We'd love it, absolutely love it.

Justin Garrison (36:03.473)
Mm-hmm.

K.S. Bhaskar (36:08.066)
Satya Nadella says, we love Linux. So I think that really summarizes the cultural shift that has happened where people saw open source as a threat. Now they see that as an opportunity. And the sad part is now they see taking the software, you have these open core licenses and openish licenses which aren't really open source, but which source available licenses.

Justin Garrison (36:30.375)
Yeah.

K.S. Bhaskar (36:37.048)
So that seems to be going in the opposite direction. But I can see why people want to do that because certainly making money in the open source business is hard. But then making money in any business is hard. If I were running a restaurant, think making money in the restaurant business would be hard.

Autumn Nash (36:46.741)
What?

Autumn Nash (36:52.725)
Very true. I just want to say that talking to you is a joy. you just, your energy just like totally makes me like so excited. What got, what started you with your love for Linux? Like what made you, what drove, what attracted you to Linux and what's kept you there for so long?

K.S. Bhaskar (37:11.352)
So it's open source Unix. So I've used Unix for many years. In fact, my first personal computer was a Unix computer. It was an AT &T 3B1 that had like a 40 megabyte disk and two megabytes of RAM or something like that. And it ran Unix. And then when I got to Linux, the first Linux I got was actually a Linux that

the entire Linux was on a floppy and you booted off the floppy and you ran it and it gave you a shell. So it is like, cool, here's this Unix system. I have access to all the source code, I can play with it and that kind of got me into Linux in the first place. And so I kicked the Windows habit probably around 1999 and...

Justin Garrison (38:00.547)
You missed XP. That was a good wave.

K.S. Bhaskar (38:01.99)
I will actually bought a used laptop once it had XP but then I installed Linux on it.

Justin Garrison (38:08.818)
All right, that's good.

Autumn Nash (38:09.533)
Yeah

Autumn Nash (38:14.805)
What do you, if you had to pick one part of your career, what was like, like what was the most exciting, I guess the highlight or what would you take away if you had to tell like your younger self about like this career that you could not have imagined? Like.

K.S. Bhaskar (38:31.424)
that's hard to say. think that I've enjoyed every bit of it. I've actually changed jobs very few times, only three or four times in my entire career because I've enjoyed doing what I do. So what I would tell my younger self is just to keep doing what you enjoy.

Autumn Nash (38:54.647)
Do you have any, sorry.

Justin Garrison (38:54.886)
I go back to what you said about being in business, it's you're making money or you're having fun. And I feel like in a lot of ways that second piece on having fun is not what you're doing. Like you're making fun too, right? Like you are creating the fun you want to have. You are making money and you are making fun to be able to enjoy this, right? Cause we can make work into a lot of different things and we can say, this sucks. I hate everything.

But if you kind of go into it with excitement and wanting to learn the things and wanting to push yourself, you get to make your own fun. And that's really cool. That's what my kids do all day, every day, right? They get to play with their friends. They get to create fun out of nothing.

K.S. Bhaskar (39:34.158)
Sure. You have to.

Autumn Nash (39:34.955)
That's the best part about being a parent, I think remembering that.

K.S. Bhaskar (39:39.118)
I always, you know, even when I was a kid, I would fiddle with stuff. So back in high school, in high school biology, I was in ace at dissection. And that was a time when, you know, Christiane Barnard and Denton Cooley and others were doing their first heart transplants. So I said, you know, this is cool. I could do a heart transplant on frogs. So one...

one evening I found two unfortunate frogs in my backyard and I found that it was much easier to take a frog apart than to put it back together.

Justin Garrison (40:19.922)
I mean, I feel the same way about my VCR when I was a kid, but man, a frog, that's...

K.S. Bhaskar (40:26.082)
Well, so, you know, I've got other stories like that too. You once I opened my watch, I had an old mechanical watch from back in the 1960s and, you know, I tried putting it back together and I had enough pieces left over for the second watch.

Justin Garrison (40:44.115)
For sure. How does that apply? I feel like that happens in software too. In software, I go to refactor something and I'm like, why do I have so much left over here?

K.S. Bhaskar (40:56.046)
sure, that's absolutely true. It's understanding how things work, whether it's software or whether it's hardware or whether it's an animal. It's understanding what makes things tick.

Justin Garrison (41:02.279)
Yeah.

Justin Garrison (41:08.742)
So help me understand YodaDB a little bit, right? Like that's the code base and the company that you founded, you've been working on for so long. Like on the website, the fastest key value database, right? Like what makes it that fast? Why does it function in that way? And why is that something you've been doing for so long?

K.S. Bhaskar (41:27.512)
So, I mean, what makes the RDB so fast, I think, is just it's an obsession with speed. I mean, actually, speed is second. The first thing is it's an obsession with correctness. Because if the software doesn't have to be right, then you can make it arbitrarily fast. So, know, speed comes first. But we do obsess over speed.

Justin Garrison (41:40.37)
Databases have to, yeah.

K.S. Bhaskar (41:55.678)
And even from one release to the next, if you see any kind of slowdown, we go through, we analyze why it is that way. It is just something that we do naturally. And so right now, the next release, for example, we're looking at rewriting the garbage collector just because that's a potential opportunity. So I think that that's where it comes from. And again, the way that it was developed, it was developed at a time when computers were

know, a thousand times slower than they are today. And when you do that, then you naturally focus a lot more on performance and that kind of carries through in the code base all the way to today.

Justin Garrison (42:38.438)
Now key value data stores tend, like I know a lot of people that treat them redis, right? It's a cache. I don't actually care about the data. It's throw away information. I could rehydrate this somewhere else. But then I also think on the other side of that on things like Kubernetes and etcd, another key value database that's really important, but also intentionally.

fault tolerant for being distributed, right? We want something that's distributed so that we don't ever lose information. And on the other end, we have this, I don't really care about it, I just want it in RAM and it can go away at any time. Where does YodaDB sit in that sort of scale?

K.S. Bhaskar (43:15.234)
Well, there's a third dimension to that, which is that you do care about the information, but in our case, we also care about, so say, let's say, know, distributed database. You're never going to get high transaction performance with the database. In our case, transaction performance is absolutely important for high-end banking systems. And at the same time, you know, having the data be

The integrity of the data is is bad about. So we have different techniques for doing that, basically replicating in real time to different replicas, but having one system be essentially the system of truth at any given instant. comparing it to Redis, though, people often use Redis as a cache. Now, in our case, we're faster than Redis and we're a database, so you don't really need a cache.

Justin Garrison (43:59.027)
Primary. Sure.

K.S. Bhaskar (44:12.376)
You just use the database directly. And I think there was a question that you had when you didn't actually articulate it, but you were kind of wondering about key value databases. It's important to remember that the very first databases were actually key value databases. In fact, the very first database was a key value database. It was developed by Rockwell and IBM for the Saturn V Apollo to manage the bill of materials for the moonshot.

and it was developed in the 1960s and that was a key value database. And that database, by the way, is still running today. It's an IBM product called IMS. And, you know, and then, so go ahead.

Justin Garrison (44:53.594)
What, why did they write a database? Like I don't actually know the history. like I imagine we start with files on disk and we just say, we can't have two things right to the file on disk. And so we need something else to handle deletions and whatever, like locking, whatever the case may be. And so at some point we like changed from saying this file that I'm writing to is now a database.

K.S. Bhaskar (45:19.522)
Well, it's not just the access control. It's also the fact that you need to search and retrieve data. So yes, in theory, you can just take a flat file and any flat file as a database. But on the other hand, finding information in that flat file or updating information in the flat file can be challenging if it's a big file. And that's where databases come in.

Justin Garrison (45:49.307)
At some point we, I mean, there's still files on disk, right? At some point they're like, there's bits on a disk, but how I index that's how I make sure I can quickly access the right information and update or write new information.

K.S. Bhaskar (46:02.466)
That's exactly what the database is. And ultimately, as a database developer, we rely on the integrity of the underlying file system. So if the file system gets corrupted somewhere, then we can't really use it. Because when we write data to the file system, we expect to get it back.

Justin Garrison (46:23.814)
I bet you have some stories there about file systems that didn't give you that data.

K.S. Bhaskar (46:28.578)
Well, mean, today there are only two file systems that we consider fully supported, EXT4 and XFS. So we consider F2FS kind of supportable, but not necessarily supported. we tell our customers we don't support ButterFS, we don't support ZFS, we don't support NFS, because we have found in our testing that they're not always reliable.

Justin Garrison (46:53.382)
That's fascinating because I always think of ZFS and ButterFS as having more checksums and more, you know, they have protections against bitrot and all these things that XFS and EXT4 doesn't have.

K.S. Bhaskar (47:09.602)
Well, in our testing, we routinely run, we've got a couple dozen computers out here, we're constantly testing. And we have found situations where ZFS and buttered AFS basically don't give us the data that we expect.

Justin Garrison (47:24.562)
Hmm. That's fascinating. even thinking back on before we had journaled file systems, with whatever you were writing, you hope it wrote to disk before the power goes off, right? Like there's a lot of situations that we've come a long way in those areas to make sure file systems were pretty reliable.

K.S. Bhaskar (47:45.614)
Oh, actually, I do have a story on that, in fact, which is that when the upstream code base first went into production back in like 1986, someone accidentally at a data center kicked out the power cable of the computer system. And they found that there was a bug and there was like two or three weeks of data which had not been recorded in the database. So the vendor actually sent all of the team down to

Justin Garrison (48:09.136)
my gosh.

K.S. Bhaskar (48:15.01)
the customer site and unfortunately that time they still had the paper records. So basically everyone had this crash project to go put the paper records back in the database and also fix the bug in the database so that everything got written out to disk.

Justin Garrison (48:20.172)
Justin Garrison (48:34.082)
We started this conversation talking about having difficulty with things occasionally and still trying to learn new things and banging your head on the wall, trying to figure out like how things are working. What are the things today that you might still struggle with learning or trying to pick up when you're building it?

K.S. Bhaskar (48:55.054)
Well, mean, certainly one of the things that I'm struggling with right now is AI. I find that it's useful. sometimes when I, you like I had to replace my laptop battery over the weekend and I was kind of wondering why the old battery died after just two years. And I went to do some research and found that, you know, I shouldn't charge it to more than 80 % if I...

So then I said, how do I keep it within that limit? And basically I went to, I asked a couple of different AI models. Ultimately I find DeepSeq to be the easiest one to use for me, but it gave me good information. But where to have the problem is understanding what it's doing, what it's been trained on, how is it giving me that answer? And it doesn't seem to know its limits sometimes.

Justin Garrison (49:54.737)
Yeah, for sure. It's so confident in the information it gives without knowing where the boundaries of

K.S. Bhaskar (50:00.078)
Right, then something like my laptop battery, not particularly important. I also asked it about recipes for pasta sauce when I was cooking dinner a couple of nights ago. It did all that well. But then when you think about using AI to predict, some people are trying to do this, someone who is going to commit a crime before they commit a crime.

Justin Garrison (50:27.57)
you

K.S. Bhaskar (50:28.224)
or you have face recognition software where it's been trained well on, let's say, white males, but can't really tell other people apart. And there are enough cases of mistaken identity. So those are the kinds of things where I'm certainly concerned. I don't have a good grasp on it, and I don't feel that we as a society have a good grasp on it.

Justin Garrison (50:54.226)
or at least the people that have any sort of graphs on it have a vested interest in making sure other people don't understand it, right? Because as soon as it's not magic and it's just a technology.

they kind of lose power of being able to train on whatever data they want. Because right now, looking at what they train on is copyrighted material. And they can spit out that copyright. They're like, oh, no, we have to have this because you don't understand how AI works. And then at the end of the day, it's like, no, that's what Google did back in the day, where they just said, we're going to scan every book. And then when you sue us to say we can't scan every book, we're going to say, oh, OK, we'll stop. But we already have the books. We already have the data. We're fine. We'll keep.

K.S. Bhaskar (51:33.346)
Yep, yep.

Well, and the other thing is AI certainly has had a whole bunch of, know, hucksters come out there that say we can, you know, here's all this magic that we can do and trust us it's going to work.

Justin Garrison (51:48.464)
Yeah.

Yeah, and again, a vested interest in making that money and making those promises that this will grow forever and they can do anything they can. But at the end of the day, LLMs, at least to some extent, are fancy databases.

K.S. Bhaskar (52:07.904)
sure.

Justin Garrison (52:09.356)
and rely on a lot of that data structured in certain ways. I've been learning a lot about vector databases and just like, what do they do? How do they store data? Why is it important? And why did we even need a different type of database for this sort of thing? So yeah, that's very fascinating.

K.S. Bhaskar (52:27.576)
Well, that's something I've been thinking about because if you think about YaraDB, we have a, at the core, core technology is a key value data store. And on top of that, we've, for example, we have a SQL layer. Ultimately, a key value data store is the most general type of data store. And so we can put SQL on top of it. I've been thinking about what would it take to put a vector database layer on top of it? And which one would we want to be compatible?

So it certainly is something that ultimately, when you have an AI system, there's a large vector database somewhere that's actually storing the data. And they have some efficient access to that data to make it work.

Justin Garrison (53:13.254)
Do you think it's a fad? AI vector databases?

K.S. Bhaskar (53:18.988)
No, it's not a fad. I think that what will happen is eventually people will realize what the limits are. But they're still useful. They've proved their usefulness. And once something is useful, it's not going to go away. It's just that people will keep pushing it. when it gets to the limits, then people will move on to something else. I kind of like search engines, right?

When search engines were great, people used them, they kept pushing them. Then they said, with search engines, can now, Google came along with Gmail, and they came along with, and some things worked like, Yahoo came up with the idea of a portal, but that didn't really take off from a business point of view. But ultimately, we got to a point where people realized the limits of search engines, and then comes along AI, and that's something that, if you think about it, it's like something that sits on top of a search, on top of many search engines.

Justin Garrison (54:17.51)
Yeah, I've been thinking about that a lot. think that to me, AIs are kind of a search engine 2.0, right?

where search engines, looking back even further, like early internet days, right? Like they were manually curated lists of websites that, know, Yahoo kept and said like, here's the websites you should go to to find some information. And then AltaVista and stuff like, oh, you can dynamically find this information. And we'll make that a little better by making you, give you the most reputable source for that information, right? That's where we kind of ended with Google. And I feel like the demise of Google as a search engine specifically,

place for AI being the next search engine where I don't actually care on what one website says about a pasta sauce recipe. I care about what a hundred websites say about a pasta recipe and just give me the grouping of that thing and right now they're obviously very wrong. There's been plenty of cases where

Gemini says put glue on your pizza and do things that are completely absurd but in general in that probably is like the weights for those systems are like Over indexing on what they think has more authority like reddit reddit has a lot of authority because there's lots of people there but it's also very sarcastic which is where that stuff usually comes from and so I think that that

K.S. Bhaskar (55:16.312)
you

Justin Garrison (55:35.663)
AI systems eventually become that sort of, don't want to go to one link. I want to get a summary of 50, the next three pages of links, and you just tell me what they all said together in one summary and just give me the grouping of it, right? Like the nine out 10 doctors recommend sort of thing, instead of going like, I'm going to pick this website for that specific thing. I just want to know, like, what do they generally all think?

K.S. Bhaskar (56:00.558)
Sure, in fact that's exactly it. If you go back to, you know, mentioned AltaVista. One of the problems with AltaVista, at least for me, that when I switched from AltaVista to Google, was like I do a search and it would come back and say here's 60,000, you know, websites that answer your question. And Google on the other hand, because of the page rank algorithm, you know, you probably got 10 links which were useful.

Justin Garrison (56:25.894)
Well, even the fact that Google put like they still have it. I'm feeling lucky, right? If I go to Google, I haven't been to Google.com for so long. just yeah, the second button, I'm feeling lucky. Like that was the unique thing of like, I will give you the top.

It still exists on their website today because you're right they over index where Yahoo said we can curate a bunch of lists But that was a limitation on people managing or reading stuff altavista came along said hey our database is so big You can't even believe it. We will give you a hundred thousand links for this thing and Google said I'm gonna give you one Right. I used to Google stuff and say I'm feeling like no one does that today I don't know why that button still exists But that was the that was the selling point was like we could take all of the database of we do have a hundred thousand things But we're gonna give you the one

right thing and and maybe Jem and I should have just been the I'm feeling lucky button all over again right like that's we're all back to that point of like I don't care about the one link though I care about the grouping of what all the links thought together

K.S. Bhaskar (57:15.982)
you

K.S. Bhaskar (57:24.504)
How do you know the Gemini isn't that I'm feeling lucky but they put a language thing in front of it?

Justin Garrison (57:29.808)
Yeah, it very much, it could be. Batch guard, this has been so much fun. Thank you for coming on the show and talking to us about just everything. Like all of your experiences, what you've been doing with YodaDB, why it matters. Like why is it still even in the year 2025, like why high performance flexible databases are just kind of important. That's been so much fun.

K.S. Bhaskar (57:55.534)
Thank you for inviting me. It's been fun talking with with Otto Menu.

Justin Garrison (57:59.846)
Yeah, thanks so much and thank you everyone for listening. We will talk to you again soon.