hpr-knowledge-base/hpr_transcripts/hpr2592.txt

Episode: 2592
Title: HPR2592: Tech Talk With Allison
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr2592/hpr2592.mp3
Transcribed: 2025-10-19 06:19:55

---

This episode of HBR is brought to you by Ananasthost.com.
At 15% discount on all shared hosting with the offer code HBR15, that's HBR15.
Better web hosting that's honest and fair at Ananasthost.com.
Hello HackerPublic Radio, my name is Siglob, also known as Assembly Summly, also known as Nathias.
With me today is Allison, Heather, and we're going to talk tech and other such things.
It'll be a blast.
Allison, so you from Rumor has it that you have a few web projects going on at the moment.
The big thing that I'm working on right now is on a little project called ResourceCommunity.org.
This is something that's close to home for me because I was recently displaced and I ended up in crisis houses and various places like that.
People were always telling me about these resources that are on the community.
This privilege information isn't it?
This isn't really being broadcast to people who are out in the streets and stuff like that.
I was like, how do we get this information in front of people who are actually going to benefit from it?
How do we keep track of what the needs are on the community and how they're being met?
My website is kind of along those general lines where the first priority is just like to let people list resources that are in communities so that people are aware of what's geographically close to where they are.
So it's peer-driven, that's what you're saying.
People can identify resources then post them and people can post about whether they had good experiences with these resources or bad experiences.
Some resources are better than others.
I've not actually been in one but I've heard a lot of bad things about homeless shelters and that kind of thing.
People get their stuff stolen or want to hear it too.
So I definitely want to get actual feedback from people because I feel like there's a stat to like, well, we're providing them a place to live.
They should be happy just to have that and I don't really buy into that.
If homeless shelters are in a calm day and people then people aren't going to want to stay there.
So do you envision most people getting this news, not this news, but get this resource through libraries and stuff like that?
Libraries are cell phones. I know that homeless people do have cell phones.
I don't know if they have data on them but they do have a cell phone.
Well, I definitely want it to be a very Obama.
I want to make it a very user-friendly type site so people are on their cell phones.
They can use it easily but it should also work well if they're just in the library or something like that.
This is a technical question. This is something in my own web development.
I've written some websites that are pretty much desktop only.
So you have an user agent string. Do you defer, do you infer whether the browser is mobile or not through that string?
Does there can be so many strings? You know what I mean? Each device is unique.
In other words, how do you know that your browser is mobile?
That's a good question. It's done in the back end, in my case.
I do the detection on the back end through the websites built with Sinatra,
which is a framework for Ruby development on the web, which is on top of another kind of thing called a rack that interfaces the web server and makes stuff happen.
So, you know, I've got a basically function built into the code that just says, like, is the website mobile?
Or is the web browser mobile? And if it is mobile, then we can include stuff in the page templates that we wouldn't if it was on the desktop.
But it uses the user agent string. I don't remember where I got the code from exactly, but it's kind of this complicated thing to...
It seems like it's pretty accurate in general. I'm not sure if I...
It's good that it's accurate.
So that leads us to the next interesting topic.
The back end, you had mentioned Ruby.
So, I'm a big fan of Ruby and...
Allison, Allison over here is a Ruby junkie.
I am a Ruby junkie, yeah.
The thing that I like, you know, about Ruby is it's such a cool, like, get it done language.
You know, if you just need something to work and you don't want to spend like a huge amount of time on it, you know, Ruby's got libraries, you know, Ruby's got very...
You know, user-friendly APIs that you can work with, but also the design philosophy behind Ruby is very cool.
It follows something that is called the principle of least surprise, which basically means that, you know, if you are familiar with the Ruby language and you know how it works, then if you try to do something that you've never done before, chances are it will work exactly the way you expected it to.
That's good.
So, what do you use for your database, typically?
So, I use CouchDB, and I went through like a lot of different, no SQL database, because I'm not a fan of SQL, I think that, you know, it's time has kind of passed, and I think that...
You think it's time has passed?
I do, I think that is the general consensus, because there are security issues with the SQL database.
There are things that, you know, SQL is kind of inefficient at doing that on new SQL databases.
There are like three things that I do in SQL, right?
Yeah, and so, is it too complex? Is there too much to the SQL language, do you think, too much functionality?
I think so, you know, I think it's become kind of bloated over time. I think it does more than it needs to, really.
Yeah.
The really neat thing about CouchDB is that it's got these things called views, and they're similar to queries, but they're actually written in JavaScript.
Right on, that's awesome.
And it's really easy to like do the same things that you would do with a query with these views.
It's kind of cool that you can potentially have your entire stack be JavaScript,
aside from HTML and CSS, but that's kind of cool.
But anyway, these views, we're talking about views.
Yeah, I'm not going to like get into the technical details,
mostly because I don't remember of them, but basically, yeah, you just construct a view based on some simple JavaScript code,
you know, basically give you a list of elements that you can kind of run through.
You can get the first element into the last element, and basically based on the view that you construct.
Hi.
That's interesting.
So, what's your license for the website?
Is the backend available, or what do you think about copyright in general?
Well, good question.
So, you know, I'm not like a huge fan of copyright, at least,
not the way that, you know, it's implemented today, suddenly.
Yeah.
You know, think that, I mean, copyrights that go like, what, the life of the other, just like 50 years?
Yeah, this is ridiculous.
It's, you know, my position on this is, and pretty sure that, well, I'm not sure,
but, you know, I think this is a pretty reasonable explanation for why things are that way,
is because, like, a lot of media companies are afraid that if the copyrights get short enough,
then they're basically going to be competing with themselves.
Oh.
They're with their free stuff.
They'd be competing with their free stuff.
Yeah, like, for example, if a copyright term is only like 10 years, well,
Yeah.
10 years later, you know, they're going to have to be competing with all the stuff that's now free
that they made 10 years ago.
Well, what, how do you, how do you feel about that being incentive to make more,
like, make better and better things?
I mean, I think that's the kind of way copyright was supposed to work.
I think, you know, it's supposed to create incentives for people to create better and better things.
Yeah.
Well, yeah, copyright is a monetary incentive where you monopolize any of your work for a certain period of time.
But, um, yeah.
So, um, yeah, personally, like, I don't really, you know, have any interest on specifically holding a copyright
for things that I've written, like, um, basically, um, I'm a fan of creative comments and stuff like that.
But, like, for me, when we're talking about my code, you know, it's usually like the MIT license or something like that,
basically, like, totally permissive, not restrictive.
I'm, I'm most familiar with the BSD and the, the GNU license.
What, can you talk about the MIT license and, and what attract the new to it?
Um, well, I don't remember exactly what it says, but it's like, pretty short.
Basically, it just says, like, do whatever you want, but this code, as long as you retain this license.
Oh, okay.
There are lots of licenses that are kind of similar to that and have like minor differences.
Oh, yeah.
Okay.
The MIT license isn't even the only one I've ever used, but, um, I, I've used the GNU and BSD in my day.
Yeah.
And public domain, I have a couple of public domain programs.
So what's, okay, so you do all this coding, like, what was a, what, what was your favorite project to work on?
Is there a favorite, or is there just so many that, like, you don't know?
Oh, God, well, I've, um, I've got like a lot of unfinished projects, you know, it's kind of been a thing for me where I,
I don't know if you can see this audience through Hacker Publicated, but I am raising my hand in, in agreement, I am also the queen of unfinished projects.
But, okay.
Yeah, um, so, I mean, you know, it's very easy to, um, bite off more than you can chew when you decide to start a project because, um, you know, projects very easily, you know, grow in scope, you know.
Yes.
Yeah.
When you're playing them out, so, um, for me, my, my coding, um, methodology is, don't, don't do hacks.
Right?
Like, like, code stuff as if you're, you're going to code it for things in the future.
If you're, if your application needs a GUI element, a GUI element to it, make a GUI that other applications can use.
My guy found that's a lot easier for debugging and general maintenance of programs, instead of the shortest distance from A to B, you have to have some structure there.
Yeah, definitely.
The overarching structure of your application is something that you really do need to, um, keep in mind.
Yeah.
But, um, you know, the flip side of that, I mean, it's very hard to, like, work on a big project with, like, multiple people contributing to it.
Yeah.
Maintain that kind of structure.
I've never done it.
I've never maintained a project that sends up people, but, like, the logistics of it is just crazy for me.
Oh, yeah.
I know.
I don't think I've ever really done anything collaborative as a programmer before.
I've always just made things, and either I finish them or I don't.
But, um, yeah.
I mean, um, they're like, um, there are a few things that, um, you know, I've done that.
Um, I thought we're neat enough to just file, like, posting them online for, um, other people to use.
Yeah.
What, even though it was kind of neat, um, was a little thing that I wrote called shimmy sham, which was kind of a simple little, um, tool that I made.
That's a ring to it, shimmy shammy.
Yeah.
Um, well, it's pretty simple.
It's basically just, like, a script to generate, um, project files for Visual Studio and, like, basically, um, skeleton application for, um,
Yeah.
A DLL shim.
So you could kind of, um, if anybody, like, doesn't know what a DLL shim is, it's basically just a DLL that sits in between the application and the actual DLL.
It's kind of, yeah, access and gets in there and messes with stuff and does fun things.
Yeah.
Um, I've, I've often had to change the linker for Linux, um, because of the lack of, like, I have this 32-bit application on a 64-bit system.
And so I have to, you know, have a link to the 32-bit linker or run with the 32-bit linker, rather.
So is that kind of a bit like shimmy sham, or you, you, um, do you actively change how the library interacts, or do you provide more functionality, or you just completely replace calls with your own stuff?
Um, well, you can do all of the above, really.
You can add, you know, functionality, but it's hard to do that because you can't, like, change the interface.
Yeah.
I mean, the DL, the actual interface, you know, the function calls within the DLL have to still work and do the thing that the calling application expects them to do.
Yeah.
But, um, like, if you want to basically, um, the main thing that I actually used it for was, like, to, um,
interface with, like, the, um, the input library windows, like, the X input library for controllers, and to, um, to try and, like, make it more compatible.
Because I had, like, this controller, and I wanted it to work on all my games, and I was like, there was actually, this is not to get too deeply into the subject, but, like, the controllers.
No, we have the time.
Yeah.
Well, just, like, a rough overview, like, the controller support on Windows is kind of a mess.
They've got this thing called X input that, um, a lot of things used, but there's also direct input.
And, um, I think they also have, like, controllers with raw inputs.
That was, like, three different ways you can interface with the controller.
A lot of games don't let you change the controls.
Yeah.
Um, so, like, if you have, like, a game you want to play in, you don't only have one controller, and it's not, like, an Xbox can play something like that.
It can be a pain to actually get to work sometimes, so.
But, um, Windows is kind of a jerk about, like, loading ShimDLLs.
Like, um, I didn't actually really address this problem, but there are some, you know, system DLLs that, um, Windows, like, will refuse to load anything with the actual,
you know, system DLL, and, um, yeah.
I think it's, you know, a pretty, a pretty safe assumption that they did this for security reasons, but.
Oh, yeah.
Yeah.
But you'd have to, like, resort to other techniques, like, DLL injection to actually get us in DLL with those type of...
Yeah.
...shown mother-fucking-web.
Uh, Latira Osel, he has done a lot of work on Shims for, for libraries, for else, and stuff like that.
Um, research in, he's a pretty right guy.
So, um, let's see here.
Is the work on anything else that's interesting?
Um, well, let's see, um, I don't really have anything other than the, um, resource community web page that I'm working on right now.
Yeah.
Like, the first project that I ever worked on, which I think it was interesting, was, um, like, the first big project I ever tried to code was an emulator for the Sega Dreamcast.
Yeah.
She's, she's trying to get the emulators.
Oh, I don't know if this is coming across in the recording, but somebody is really kicking the bass out.
Oh, yeah.
You can't hear this.
Maybe you can.
There's a car out there, and the bass is insane.
Yeah.
It's shaking our window.
Um, but so anyway, yeah, um, my first project was trying, um, right, a Dreamcast emulator.
And, um, I got as far as, you know, the processor emulations, it's like that.
I was trying to write it in the S-H2, right?
S-H4.
S-H4.
I was trying to write an emulator that, um, is really super complicated.
Sega Saturn was just like a monster of a console that, um, you know, was the result of many
questionable design decisions, but, um, but it's also really neat, like, on it.
It does, um, it, um, actually kind of renders 3D objects using two dimensional textures,
like sprites that have been, uh, transformations applied to them.
Um, uses quads instead of polygons, but, um, I just, I just wanted to, um, give, give a shout-out
to Steve Quack who, um, Steve Quack Mopos.
Yeah.
Who is currently working on, um, a Sega Saturn emulator called Nova, which I support on Patreon.
I don't really ask him to take on the Saturn, because, um, you know, very few people have been
up to that challenge.
Um, only, um, emulator that, um, was, you know, half reduced into the Sega Saturn before
that was called SSF.
Okay.
And, um, it was a pretty good emulator.
It was only for Windows, unfortunately.
I think, um, the author's name was Shima and he was from Japan.
Okay.
He did a pretty good job with it.
I mean, it runs most games pretty well.
So, um, so the, the, uh, I don't know much about the Saturn.
Was it two SSH2?
SSM2?
SSH2, sir.
Yeah.
I believe it was two and then it had a splitters around top of that.
Yeah.
As to all the consoles of that age.
Mm-hmm.
So, yeah.
But, um, no, my emulator was just for the Dreamcast, but, uh, like I said, it didn't really do.
Did he, um, did he have to, um, so the SH4 has memory management unit, which is good if you
want to run BSD or whatever on the Dreamcast.
But, did you find that a lot of games, to a lot of games used the, the memory management unit?
Well, to my knowledge, no.
So, Sega had their own development kit for the on Dreamcast called the Katana.
Okay.
That was the library, um, the library.
Oh, yeah.
I think, um, is it, is it available?
Can you, can you find this library?
I think it's been linked, and it's, um, sweet.
Oh, sweet.
Um, but, um, there was also Windows CE for the Dreamcast.
Yeah.
There was Jesus Christ.
I forgot about that yet.
And I do believe that Windows CE games did take advantage of memory management.
I don't quote me on that, but I'm pretty sure they did.
Um, I don't think any other games that weren't Windows CE actually used the memory management.
And I don't think it really bore that many games that were developed on Windows CE for the Dreamcast.
I think Sega's development kit was by far the most popular to write games on.
Oh, okay.
So, coming in.
But, um, yeah.
So, um, I didn't really get, like, super far with the emulator, but it was a really good project for me,
because I learned, like, a lot about the level programming assembly from that project.
And, um, I've, like, continued to, um, use those skills.
My, my big, um, contribution to the Dreamcast scene was that I did an Undub of the game,
Grandia 2, which you can still find out there.
You did an Undub?
Undub.
Uh, basically, um, the game was dubbed in English.
Oh, dubbed, okay.
Yeah, the Japanese voice acting was dubbed in English, and they took liberties with it.
You know, the, um, I wasn't, like, a huge fan of English voice acting in that game.
So, um, yeah.
I kind of took it upon myself to, um, try and restore the original Japanese voice,
because it was really hard, because there were a lot of, like, technical hurdles, like, um,
I'd edit files that were in, like, a prior to a compression format.
Yeah.
Uh, thankfully, somebody else had been the tool to decompress and compress them.
But, um, yeah.
But, and I had to do some reverse engineering to, um, figure out, you know,
how to modify certain parts of the script without causing the, you know, game to crash,
and stuff like that.
So, um, it was challenging.
I also re-translated the spoken parts.
Right.
Um, the original Japanese back in English to be more true to what the original Japanese said,
because the English translations were not really, you know,
they were sort of there.
But, you know, they were definitely not, like, little translations.
All your, all your bass are belong to us, for instance.
Yeah, not quite that bad, um, definitely, you know, it was better to go back to the original Japanese
and get back to what they actually said, um, and it was a lot better to, you know,
I made sure that the script, because part of the, um, the, what the game did was,
kind of, the text would display as they were talking,
and you wanted the timing to be synced up with the Japanese version,
yeah.
It's interesting.
And various other things like that.
So, it was quite a project.
You know, a lot of end ups are basically just as simple as copying some files over,
and then it's end up.
Yeah.
But this was not the case for Grady, too.
It took a lot of work to make it happen, so.
We're not.
We're not.
Are you, are you rocking the, uh, the Linux, uh, the BSD, or the, uh,
Tycoon, or anything like that?
B-O-S.
Oh, God.
I know that.
Yes, yes.
Um, I'm, I kind of wish that Tycoon, you know, had a little bit more,
momentum as a project, because I really loved the idea of somebody recreated B-O-S.
I was.
Yeah.
I was, I was kind of a fan of B-O-S back in the day, came on.
Yeah.
You know, it, it, it was like a really cool alternative windows at the time.
Like, it was like a magic when you could have two programs playing audio,
ones back then.
Yeah.
That was like so amazing.
Yeah.
So, um, that's cool.
I, who is, is, I don't know much about it, but I, it's very modular from what I understand.
Yeah.
A lot of threads in Haiku.
Yeah.
I, I don't know a lot about the technical ideas, but, um, so, what, what you do know, however, is
you're thinking about, uh, this new operating system, can you tell us about it?
Well, like, originally, I, I had like an idea where I wanted to just create my operating system
and scratch, like so many people.
Oh, yeah.
All the cakes are like, this is, you like stuff.
It's pretty neat.
I shouldn't write my own.
Yeah, yeah.
Um, yeah, writing your own operating system, you know, it's such a neat idea, right?
I mean, it's a lot of work.
Um, yeah, it's something that, realistically, my brother-in-law is making a paper computer.
He's done with that.
Then he's going to write a compiler for it, and then write an OS for it.
Like, Jesus Christ, you're taking on way too much.
Yeah.
You're probably going to finish this.
It's, it's too much to do.
But, you know, my attitude, that's kind of shifted a little bit.
You know, I realized that, you know, my original ideas weren't really practical in the sense
that I didn't have the time to actually use them as any of them.
And what my interject was was the only person I know that, like, like, like, like,
could work on multiple layers like that.
But, okay.
So, yeah, yeah.
Um, so, so basically, I got to the point where I was like, um, you know, I'm just going to drop this entirely
because it's not a practical end, um, but recently, I've been kind of revisiting the idea.
Because I thought, okay, so, here's the problem that we're actually trying to solve
by this project, you know, not we're not, we're not trying to solve the problem of,
oh, the operating system doesn't work at all.
We have to re-optimate everything, you know?
Yeah.
So, it's so horrible.
It's unbelievable.
We can't do anything with today's thought.
Yeah.
No, that's not actually what we're trying to do.
We're trying to do is just make things more modular, you know, make things so, um,
rather than having applications be these monolithic things, the end kind of compile as a whole.
And, um, they're like their own universe where everything that happens in the application stays
in the application, you know?
Ah!
Whatever happens in the application stays in the application.
I like that.
Yeah, yeah.
I kind of use this.
Well, that's kind of the, um, design philosophy to, um, you know, applications right now.
Yeah.
I like that, that idea is flawed because, you know, very monolithic, very monolithic.
And I think that, um, you know, modular design is a really powerful thing because, you know,
you can reuse that stuff.
Yeah.
And, um, you know, I can't count the times when I thought, you know, it would be really nice if I had
this functionality from this other program and my program, but actually making that happen,
I don't even know where to start, right?
Was this similar to, uh, herd or micro, micro kernels or anything like that?
I honestly don't know enough about how herd is actually implemented.
I don't know much about the herd either.
I think that, um, you know, the idea of micro kernels is definitely similar, but, um,
but you're, yeah, you're, it looks, it sounds like you want a standard protocol for all units.
Well, yeah.
So, basically, um, and this is something that I really get from the design philosophy of Ruby,
because, you know, I was the great things about Ruby is that, like, if you need a library to do something in Ruby,
yeah, it probably exists, you know, because, um, you know, people who solve problems in Ruby,
they tend to do it in very, you know, modular reusable ways.
Yeah.
Because that's just like part of the philosophy behind the language, right?
Yeah.
Nice, nice connection to the beginning of the interview there.
That's, that's good.
Um, not intentional, but okay.
It's good.
Yeah.
So, um, basically, yeah, with, um, the whole modularity thing, it's like, um, so we have, you know,
these units of code, and we can reuse them, and that's all very nice.
But again, Ruby is still its own universe, you know, what happens in the Ruby, um,
interversities in the Ruby unit of interpreter.
Yeah.
And I'm like, you know, really, we're, while I'm out here, while writing code, while trying to solve problems,
we want to be able to help each other do that, you know?
Yeah.
And it's not very efficient when we're all like creating these model of the creations.
Like, Unix is still long.
Unix is very much about the application, you know?
And definitely design philosophy is kind of built around that.
It's like, um, there's a tool for everything, right?
That's kind of the Unix design philosophy.
But the problem is that all these tools kind of work in their own different ways.
Yeah.
I think it's, it's can be tedious to learn how to make a tool do a certain thing.
Yeah.
Um, if you actually want to mess with the functionality of a tool and get into its inner workings, you know?
Yeah.
So you're quite a lot to take on.
You're going to have to.
It sounds like you're going to have to figure out a homogenous way to interact with other objects.
Well, so Ruby already does this pretty nicely.
And that's, you know, kind of the, um, nice thing about, you know, the Ruby design philosophy is that you can pick out a lot of details at this.
Yeah.
And you can say, this is very nice.
But ultimately, you know, Ruby being its own thing, you know, it's, it's hard to make use of this in the grander context because, um, yeah.
You know, Ruby, um, first of all, I think the big thing that puts people off Ruby is that Ruby is slow.
Yeah.
Yeah, that's, that's the, yeah, that stuff.
I hear that well.
Yeah, yeah.
And it's true.
I mean, Ruby, um, is one of the slower languages.
And it's definitely a couple of.
The computers are pretty fast, though.
Well, we're not on the old 46s.
Even so, though, like, there are other concerns when you're using Ruby like a lot of memory questions.
Um, I don't know exactly what the memory footprint of the interpreter is.
I think it's gotten better.
I mean, it's not huge.
Okay.
You know, switch the imagination, but, um, three.
But, yeah, so, um, but there are other things to be taken into consideration to, like, energy efficiency, for example.
Yeah.
I mean, if we're all running this, like, super high-level stuff that is really distant from what the machine's actually doing.
Yeah.
Yeah.
It's really energy inefficient to be doing that.
So, um, energy inefficient.
Yeah.
Yeah, actually we're saying that.
So, yeah.
So, basically, what my thinking is here, that, um, we, we need to, like, take some elements of the design philosophy of Ruby and bring them down to a lower level so that we can have applications that a lower level that work more like Ruby applications, which, um, which I think could be a pretty powerful idea.
Like, that, there are some things about the way that Ruby does things that are very smart and that allow you to do some surprisingly powerful things.
Like, um, okay.
Ruby is really big on the idea of passing data in messages.
Okay.
Like, um, yeah, yeah.
A lot of, like, good to start.
Very good at that.
Yeah.
You do, yeah.
You carry strings, right?
Like, that's the interaction between units is a string.
Well, it doesn't even necessarily have to be a string.
There are, there are different ways that you can approach the whole message system.
Yeah.
But, um, the basic idea is that instead of having functions, um, you have messages or you have, um, you have methods that, you know, have messages that communicate with each other via messages.
Yeah.
So, would you, would you write like a unit of computation, uh, not a function, but like a unit of computation as an input and an output?
Um, well, yeah, basically, I like functions, everything has an input and an output.
But, um, but your input is just not a message.
Well, you can, you can have like an input that is a language pretty much, right?
And you'd be a person in your unit of execution, then.
Well, like, um, you, in Ruby, you can like pass around like, um, code, like it was data because it's an interpreted language.
Yeah.
So, you can do some pretty carved things like that, like my, my website relies on templates that are in Ruby.
The templates are really, you know, a strong feature of interpreted languages, because you can, um, fit these templates to, you know, render pages that, um, allow you to kind of interface with the backend in a pretty seamless way.
But, um, yeah.
Well, so the important thing to keep in mind about the kind of, um, message, you know, processing the advantages of it are that, um, you know, basically, when, when you're writing code, like, that uses messages, that means that you can send messages between memory spaces.
And it still makes sense.
Yeah.
That, that's like a super important thing when you're talking about demodilizing an operating system.
How would you, would you, in, in this effort to make this operating system, would you have to make your own debugger, do you think, or like, how would you sort of figure out what, what message it goes when and where and what goes after that?
Well, so back to kind of the core of the subject case. So, as I was saying, I realized that it was impractical to kind of start from scratch and make this kind of an operating system.
Yeah.
But, okay, well, what actually can we do?
And so we thought, well, Ruby, like, the interface that Ruby provides, you know, is consistent between Ruby implementations, meaning that if you're using Ruby on, like, Linux, or using it in Windows, it doesn't matter.
The interface, all the core methods, the, you know, the parts of Ruby that you use to actually interface with the operating system, being constant, no matter what operating system you're interfacing with.
Okay.
And that is really the key to bringing kind of the Ruby design class we done to a lower level and actually having it make sense.
Okay.
So, DADD is like to create instead of a real operating system.
On top of something.
Yeah, a virtual operating system that actually sits on top of an operating system, like Windows, Windows.
Yeah, yeah.
After Plan 9, there was Inferno, which is kind of an operating system on top of an operating system.
I don't know if you've heard of Inferno.
I did look it up, but I'm not sure again about all the technical details.
Oh, yeah.
I don't think that they use the type of message passing that I'm talking about to get like the interface communication going.
One thing that I would, this is kind of stepping on mail, but the one thing I'd like to do is have a lot of Raspberry Pi's.
And one connected to a screen, one connected to a keyboard, one connected to a hard drive.
And right now, such that you can transfer execution between computers like Raspberry Pi's.
Yeah.
And do you figure out the latency of input and output?
And you kind of move the program towards what is most latent or away from what is most latent rather?
And so, I don't know, that's a thought.
But so, okay, so everything is an object in your operating system.
Well, so I think that would actually be kind of an oversimplification, because like in Ruby, everything literally is an object.
And I thought that, well, I don't objectifying OSs.
I don't know, it's stupid jokes.
I mean, it's sort of like on that line of thinking, though.
I mean, because operating systems, you know, I mean Linux, you know, is written in C.
It's not object-oriented, at the core.
No.
I'm not sure what language windows the kernel is written in.
I think it's a mix of C and assembly.
Yeah, probably.
And I think most operating systems are written in C.
And so, they're not or object-oriented from the ground up.
And object-oriented programming is a really powerful tool if you want to reuse code and have it be very modular.
Yeah.
So, I think that, you know, getting an object-oriented programming down to the OS level,
could have some pretty powerful implications.
Cool.
Yeah.
What I'm talking about, like passing messages, like you were saying, like, passing stuff or, you know,
re-arranging how computational resources are being distributed across the network.
Yeah.
The great thing about message passing is it's also network agnostic.
Yes.
You can actually, you know, use the same interface to communicate with a program,
yeah, locally, as you do over a network, it doesn't matter.
It's pretty brutal.
That's fundamental.
That's cool.
So, yeah, it's, like I said, it's a really, you know, powerful idea.
You could, like, you could just have separate computers.
You could write this with, like, five computers, right?
I'll network together.
Yeah.
That would be fun.
That would be a lot of fun.
Yeah.
And you can have, like, different parts of the operating system running on different computers.
And as long as the protocols are efficient enough,
and the network is fast enough, it just doesn't matter.
I mean, yeah.
That's, that's, so, um, would you, would you, like, I asked you this before,
I don't know if I could have answered or went up, but, um,
would you be interested in, in sort of the input stage,
having a syntax aware parser, right?
Like, like, the message protocol is a language of its own.
Kind of like a, like, post-script, right?
Like, post-script does a very simple thing, a principle file.
But it's an entire language, right?
Like, post-script is a term, complete language.
Right.
And how do you feel about passing, like, essentially source code from, from, from, uh, object to object?
Well, so, taking this step back,
like, if you look at the way that Ruby handles, um,
message matching, which is, again, really smart, you know, is that, um,
What's smart about that?
Well, there is a single method in every class called the send method of Ruby.
Oh.
And this is basically, like, um, the go-between, between, um,
your class and the rest of the world.
So, the send method gets called every time you send something,
Okay.
Yeah.
To, uh, object and Ruby.
Um, I don't know, like, I think, I mean, I'm not sure exactly how they implemented
in the interpreter.
I don't think, um, they might actually call the send method if you don't define a custom,
whether they call their own send method or that kind of thing.
Oh, okay.
Um, because Ruby has the send method that you can implement, um,
you can actually control how messages are passed into, um, your programs,
or into your objects.
So, um, you basically can handle messages any way you want.
Yeah.
And, um, I'd like to keep that aspect of the design philosophy.
I don't want to try and help people that they have to use specific type of messages
or a specific format for those messages.
Yeah, just, I want them to be able to decide, you know,
how they want to communicate with each other, you know.
So, um, I don't want to dictate that.
You know, I want them to, you know, I want the communication to be very open.
I want there to be different possibilities in terms of how things communicate with each other.
Yeah.
So, um, that's basically what, um, what I'm thinking.
So, um, and additionally, like, so on the other side of this equation though,
um, it has to be fast enough because people are going to care
if things get significantly less efficient.
Like, nobody's going to use this.
Yeah.
Just be sending messages and all the time.
They're like, this is too slow.
I mean, it's, it's decreasing our benchmarks by like 50%.
This is unacceptable.
You know, we can't, we can't afford our programs.
So, the idea to get around that is that, um, you know, at the, um,
compiler level, you know, if we're going to call the objects in this, um,
operating system node.
So, um, if nodes exist in the same memory space,
then they actually can directly call functions or call methods.
Yeah.
Like, you do in traditional, um, object-oriented programming,
like C++, and stuff like that.
So, yeah.
You, when you're in the same memory space, you're allowed to make direct calls.
Yeah.
And, um, this is like really important because, you know, when you're talking about like efficiency,
you know, we're going to have the ability to have nodes, you know,
have different memory spaces, but they can also exist in the same memory space.
And when they exist in the same memory space, then things get a lot more efficient.
So, okay.
So, remote procedure calls, right?
Like, um, but NFS is based on, in SAMBA and a lot of stuff.
How do you feel about RPC?
Is RPC aware that I've never used it, right?
Is it aware that it's on, uh, both points are on a machine
and makes like a unique socket or something like that instead of a network socket?
Yeah, that, that's a good question.
I don't actually know much about the implementation of RPC.
No, I, I'm the DIY.
It's, it's, I think it's kind of looked over.
It's something that I'd like to research a little bit that would be kind of cool.
Yeah.
And I think if I actually do get, you know, deep into the whole development of this project,
then, um, I definitely, I'm going to have to look at RPC because really, you know,
since this is a rich operating system, you have to build the implementation on top of other operating systems.
Yeah.
So RPC is, well, I'm going to have to use whatever the operating systems provide for inter-process
communication.
Yeah.
Then you have to kind of build on top of that a universal interface.
Yeah.
So RPC is probably something that would actually be used in an implementation.
Right.
Down with RPC.
Yeah.
You know me.
Sorry.
Yeah.
So I, it's like I, um, I want to, you know, have, I want to get to the point where, you know,
the, uh, virtual operating system is running on top of the operating system.
Yeah.
And it's basically like, um, you can write applications for the virtual operating system.
And this will be invisible to a user.
Yeah.
And they will be using an application in, um, for the virtual operating system.
And it will load up just like any other operating system.
It will probably be like a, um, daemon or service in the background that actually, um, controls
what the low level stuff about the operating system is.
Yeah.
The virtual operating system is doing communicating with the, um, you know, real operating system.
So you can't, um, you know, make things efficient because you don't want to have to load up the
virtual operating system for every single program.
You know, that's, uh, yeah.
Oh, yeah.
That would be, um, yeah.
A problem of efficiency.
But, um, so that's, yeah, that's a problem with interpretive languages versus compound languages.
Is your loading up an interpreter for every, every program.
Yeah, but, so I can envision like a service or daemon that basically, um,
communicates via virtual operating system processes, VRPC or something similar that being the actual
implementation.
Cool.
Um, there's, there's an interesting, um, what is it?
The bugging framework for Unix.
What's the name of the, there's, there's a suite of function, a function call is two.
Set breakpoints in memory and, uh, do you like the buggy things?
And, uh, what I'm getting at is, is how, how would, how would a process look as an object?
It would be just like text in a heap and stack or, like, how would you?
I don't know.
It's not a very good question.
I don't think.
Do you know what I'm saying?
Well, yeah, I mean, um, so internally again, you've got to deal with, you know,
how existing operating systems works.
So the answer that is that a process that's using this virtual operating system is not really
going to, um, you know, look that much different to the, you know, real operating system than any other program.
Yeah.
It's going to still, you know, be packaged and basically the same format and the same type of expectations are
possibly like, um, they'll be like an EXC wrapper.
Yeah.
That would be standard and then that will load the code from the actual modules of the operating system.
That's another possibility.
But, um, the modules for the operating system probably, if like the EXC wrapper approach would allow you to have like
the modules like structured in their own different way that would make more sense to the virtual operating system.
Okay.
I can't say for sure like what that would look like in practice because I have a research that, um,
so the advantage of having a virtual operating system is you're leveraging the work that has already been
done on accessing files and data from a hard drive displaying things.
Drivers basically.
Drivers that you need.
Yeah.
So yeah, so you're looking, how do you feel about using just the Linux kernel and writing on top of that?
Um, I, again, I'm not super familiar with the Linux kernel at a low level, so it would be challenging.
Um, definitely doable though.
I mean, you could like have use the Linux kernel as a basis and then you can have this virtual operating system on top of it.
And, um, that would, that would be like how you'd get like maybe, um, the closest you'd have to like a real implementation.
Are you just writing the virtual operating system?
Yeah.
Would you, would you support like different, this is if you have windows, you run this.
This is if you have Solaris here on this.
Like, would you, how do you feel about that sort of maintaining that?
Are you sort of geared?
Is it much an X-E?
Are you gonna first do this with the buttons?
Yeah.
Um, well, windows is what my, the majority of my work has been on the past.
I have, I know, I use windows.
Oh, sorry.
Windows is completely fine.
Yeah.
I use Bing, Bing, W for my windows development.
Um, these days I'm, you know, developing on Ubuntu, which is kind of nice.
I've got a neat little laptop that I use just for coding.
Yeah.
Which is, um, it's very cute.
And you're not aware of this, but we have this table here and my laptop is on the right and her laptop is on the left.
Yeah.
It's very nice, but then.
Yeah.
Go ahead.
Yeah.
So, um, yeah, I, um, I have nothing against, um, you know, Linux.
I just, um, yeah.
I, I, I used to like bringing them out of games and it was difficult to, um,
Yeah.
The games to run in Linux.
So, to me, it just like was more efficient just to run in everything on Windows.
But, um, yeah.
And also I had kind of like a bad experience with Linux the first time I tried it.
Like it was a while ago.
Yeah.
And, you know, um, I had like lots of troubles with things breaking.
And, um, kind of sourd me on the whole, um, Linux is a everyday operating system thing.
Yeah.
Uh, these days, I think it's, you know, very usable.
Oh, yeah.
It's very usable these days.
Back when I used Linux, like you have an Ornogocard, this beautiful, um, wireless card.
And, uh, you had to patch the kernel with PCMCA support and this stuff like that.
It was miserable.
It was miserable.
Now, you can, that's the thing I like about Unix and BSDs and Linux and stuff like that.
You can swap the hard drive out, right?
One computer to another.
And have a run of the very little hiccups.
Maybe the, the, the, the, never going to faces are named differently.
But, but that's, that's about it.
Like, yeah, yeah, um, I remember like why are the support on laptops?
Oh, my God.
Oh, my God.
Oh, my God.
Yeah.
Yeah.
Oh, my God.
Yeah.
Some laptops are battlefield, right?
Yeah.
But, you know, the great thing is that, um, a lot of these problems are solved now.
Yeah.
The Linux developers have found solutions to them.
Linux kernel is very robust.
You know, it works on most hardware that you want to write it on without really doing anything special.
Yeah.
So, um, it's, it's made a lot of progress in the past.
Yeah, totally.
It's made a lot of progress.
So, and again, like I said, there's no point in throwing out all that work.
No.
And it's not practical.
And it doesn't really help anybody to throw it all that work.
Yeah.
But you still want to, you know, live in a world where if I write a program in one operating system,
it will work the same way on another operating system.
I mean, unfortunately, that's just not the world we live in today.
Yeah.
Um, but I think it's doable, you know, because ultimately, well operating systems may, you know, implement what they do in different ways.
Ultimately, they're all trying to do the same thing.
I mean, they're all trying to make stuff appear on the screen or, you know, fetch input from the keyboard and, you know,
figure out what the user's typing or, you know, communicate with, you know, external devices and that kind of stuff.
And all this stuff is basically universal.
I mean, there's, there's no reason why you can't have a common interface to all these different things an operating system does.
Yeah.
So I think that, um, you know, it really makes a lot of sense because again, nobody wants to have to, you know,
write separate code just for a different operating system, you know.
Yeah.
Yeah.
As far as like not writing a kernel again, I, uh, one thing that I do to learn is I write things that have already been written.
Like, I'll p-threads.
P-threads is pretty awesome.
Let's see if I can write my own, you know, threads kernel and stuff like that.
But it's to learn.
It's not for, it's not for producing things.
And I think that, you know, coding to learn is a very important thing because, you know, like I was saying with my dream costume,
I never finished it, but I've learned so much by doing it.
Yeah.
Yeah.
The best way to learn about something when it comes to computers is trying to fucking program for it, I think.
Yeah.
I mean, the whole idea of making a virtual operating system, right?
If I didn't have the background in like understanding, you know, how computer process it works, work it a low level and stuff like that.
Yeah.
Or the background in like Ruby and experience with super high level languages as well.
Yeah.
Then I would have no idea how to bring these two concepts together.
Yeah.
You know, I would never be able to get there if I didn't have the background.
So, okay.
Well, you know, I think it's been like 47-ish minutes.
Yeah.
I think we're going to time flew, time flew quickly.
I'm 1000 you having fun?
Yeah, exactly.
And so we're going to call it a day.
How about that?
I think that would be good.
Yeah, I think you did a lot of ground.
Yeah, I think we did too.
Thank you for talking with us.
Yeah, it was my pleasure.
Yeah.
And to check out one word, what's one word that expresses things right now.
Awesome.
Awesome.
Alright, awesome.
Things are awesome.
Take care, everyone.
Bye-bye.
We've been listening to Heiko Public Radio as Heiko Public Radio.org.
We are a community podcast network that releases shows every weekday
from Monday through Friday.
Today's show, like all our shows,
was contributed by an HBR listener like yourself.
If you ever thought of recording a podcast, then click on our contribute ring
to find out how easy it really is.
Heiko Public Radio was founded by the digital dog pound
and the infonomicum computer club,
and is part of the binary revolution at VMF.com.
If you have comments on today's show, please email the host directly,
leave a comment on the website or record a follow-up episode yourself.
Unless otherwise stated, today's show is released under a Creative Commons
Attribution Share-like Play.O license.